#fork and deterministic resumption of the resulting process

Michael van der Gulik mikevdg at gmail.com
Mon Feb 4 22:08:09 UTC 2008


On Feb 5, 2008 10:49 AM, tim Rowledge <tim at rowledge.org> wrote:

>
> On 4-Feb-08, at 1:04 PM, Andreas Raab wrote:
> >
> > What do people think about this?
> I'm not too terribly keen on the idea of a process I fork getting set
> to a lower priority than that that I requested. Then again, I don't
> all that often feel the need to fork processes anyway so perhaps I'm
> not really entitled to a vote.
>
> I think I'd categorise this example as a bug, plain and simple. Don't
> do that. It's not a nice idiom at all.
>
> To ameliorate the situation, we could *not* return the process from
> the #fork method - thus making it pointless to write foo:= [blah]
> fork. I'm sure that would upset some people that are to attached to
> pretending to be in unix-land.



It would upset me. All my code would break and I might cry.


>
>
> I'd like to hope that something like
> self critical:[foo:= [blah] fork]
>


I've never heard of a #critical: method outside the Semaphore class. I'm
assuming that self is a Semaphore? In that case, the forked/child process is
not constrained by the critical: block and will escape to begin its loop
with no guarantee that foo has been assigned.

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080205/aeaa89d2/attachment.htm


More information about the Squeak-dev mailing list