#fork and deterministic resumption of the resulting process

Igor Stasenko siguctua at gmail.com
Tue Feb 5 16:49:23 UTC 2008


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