2014-04-16 9:26 GMT+09:00 Yiping Zhang <yipin...@gmail.com
> On Tue, Apr 15, 2014 at 4:16 PM, John Mettraux <jmet...@gmail.com
>> On Tue, Apr 15, 2014 at 03:44:55PM -0700, Yiping Zhang wrote:
>> > Assuming participant's do_not_thread() returns false, worker instance
>> > would run above concurrent sample workflow in two new threads, correct ?
>> > In
>> > this situation, going back to my original question, since I want to
>> > restart
>> > worker instance, I still need to know if those two threads, handling
>> > step_a and step_b respectively, have completed their respective work or
>> > not
>> If do_not_thread returns false, the participant "consume" operation will
>> happen in a new thread. It'll happen in the current, worker, thread. IIRC.
> Aren't you getting the effect of do_not_thread() reversed here?
>> If you tell #shutdown to a worker, it will return has soon as it has
>> processing the current message. If it isn't processing a message it will
>> return immediately. Notice the #join at the end of #shutdown.
> This is true only if participant's do_not_thread() returns true.
> This is actually how my code currently work : my participant has
> do_not_thread() return true, and when I need to restart a worker instance
> (process!), I call worker,shutdown and check worker.state in a while true
> loop. Once worker.state is set to "stopped", my worker process exits.
You're replicating the behaviour of the ruote worker.
> This all works well until I also need to skip a workflow step with
> cancel_expression (see my email thread yesterday:
> After issuing cancel_expression, I noticed that the worker process is NOT
> freed up and the participant associated with the canceled step is still
> running. Since I have only one worker process configured to run, then this
> means there would be no more worker process to handle next step (the step
> after canceled step) in the workflow.
> This is the reason why I am revisiting my setting of do_not_thread() in my
> participant and the need to figure out if worker's @run_thread (not main
> thread) is busy or not so that I can exit the main worker thread.
You're not telling it but it seems you have long running work
happening in your participant implementation. Well, that's my guess.
I think you need the worker to keep track of the [participant]
dispatch threads. Sorry, it does not do it, it just fires them.