#fork and deterministic resumption of the resulting process

Joshua Gargus schwa at fastmail.us
Tue Feb 5 17:24:28 UTC 2008


Oops, sorry about the last message, I hit "reply" too soon by accident,

On Feb 5, 2008, at 8:49 AM, Igor Stasenko wrote:

> On 05/02/2008, Joshua Gargus <schwa at fastmail.us> wrote:
>>
>> On Feb 4, 2008, at 6:21 PM, Igor Stasenko wrote:
>>
>>> On 04/02/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
>>>> Hi -
>>>>
>>>> In my never-ending quest for questionable behavior in multi- 
>>>> threaded
>>>> situations just today I ran into a pattern which is dangerously
>>>> common
>>>> in our code. It basically goes like this:
>>>>
>>>
>>> Hmm, IMO, you wanting to kill two rabbits in one shot..
>>>
>>> Why not write like following:
>>>
>>> MyClass>>startWorkerProcess
>>>        "worker is an instance variable"
>>>       running := true.
>>>       worker := [self runWorkerProcess] fork.
>>>
>>> MyClass>>runWorkerProcess
>>>        "Run the worker process"
>>>        [running] whileTrue:[
>>>                "...do the work..."
>>>        ].
>>>
>>> MyClass>>stopWorkerProcess
>>>        "Stop the worker process"
>>>       running := false. "let it terminate itself"
>>
>> This doesn't work either (and is actually the reason that the
>> original, broken pattern described by Andreas was used).  Consider  
>> the
>> following:
>>
>> inst := MyClass new.
>> inst startWorkerProcess; stopWorkerProcess; startWorkerProcess
>>
>> If the first worker process happens not to notice that 'running' was
>> set to false for a moment, then you will have two processes running.
>> By comparing against the worker process, you avoid this problem.
>>
>
> It's really depends on implementation and your needs.

Of course.

>
> If you want to make sure that after issuing stopWorkerProcess a worker
> process don't running, you can modify a stopWorkerProcess to look
> like:
>
> MyClass>>stopWorkerProcess
>         "Stop the worker process"
>       running := false. "let it terminate itself"
>       self waitForProcessToFinish

(implementation-specific comment, not really on-topic for the thread)
This is undesirable because you block the "controller" process while  
it could be doing other useful work.

>
>
> Or, you can place the wait at the beginning of startWorkerProcess  
> method.
> There are vague set of options how you can control the execution. But
> it's false to assume that you can avoid such details when dealing with
> it.

I don't think that anybody is making that assumption.

>
> You _should_ know, how things rolling and how they fit your tasks,
> otherwise you will break everything.

Sounds perfect, except for these little things called "bugs".  :-)

Josh


>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>




More information about the Squeak-dev mailing list