#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
|