#fork and deterministic resumption of the resulting process
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-
>>>> situations just today I ran into a pattern which is dangerously
>>>> in our code. It basically goes like this:
>>> Hmm, IMO, you wanting to kill two rabbits in one shot..
>>> Why not write like following:
>>> "worker is an instance variable"
>>> running := true.
>>> worker := [self runWorkerProcess] fork.
>>> "Run the worker process"
>>> [running] whileTrue:[
>>> "...do the work..."
>>> "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
>> 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
> "Stop the worker process"
> running := false. "let it terminate itself"
> self waitForProcessToFinish
> Or, you can place the wait at the beginning of startWorkerProcess
> 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
> 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