#fork and deterministic resumption of the resulting process
Joshua Gargus
schwa at fastmail.us
Tue Feb 5 17:14:43 UTC 2008
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.
> 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
>
> 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.
> You _should_ know, how things rolling and how they fit your tasks,
> otherwise you will break everything.
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
More information about the Squeak-dev
mailing list
|