#fork and deterministic resumption of the resulting process
Mathieu Suen
mathk.sue at gmail.com
Wed Feb 6 10:42:49 UTC 2008
On Feb 5, 2008, at 7:51 PM, Andreas Raab wrote:
> Paolo Bonzini wrote:
>>> That's part of the reason why I won't pursue these changes here.
>>> To me these changes are just as important as the ones that I
>>> posted for Delay and Semaphore. However, unless one understands
>>> the kinds of problems that are caused by the current code it is
>>> pointless to argue that fixing them is important - I'm sure that
>>> unless people had been bitten by Delay and Semaphore we would have
>>> the same kinds of debates with all sorts of well-meant advise on
>>> how you "ought" to write your code ;-)
>> It's not that I don't think it's important. I think the *bugs* are
>> important to fix, but that the root cause just *cannot* be fixed.
>
> This completely depends on your definition of "root cause" and
> "cannot". For me, it's the fact that fork will behave in 99.99% of
> the cases in one way and in 0.01% in a different way. That kind of
> non-determinism is probably the root cause for many lingering bugs
> in our system and it *can* be eliminated.
>
>> It's just that:
>> 1) the many people who made the same mistake maybe were just
>> cutting'n'pasting buggy code;
>
> That is of course a possibility but unless you think the majority of
> people recognized the bug in the code snippet I posted, I fail to
> see how this makes a difference.
>
>> 2) especially, the fix is not 100% safe unless I'm mistaken.
>
> What do you mean by "100% safe"? It is 100% deterministic (which is
> what I care about); I'm not sure what you mean when you use the term
> "safe" here.
It may be a stupid remark but I try :)
Even with your fix that could be not safe if the event handler have a
higher priority.
Am I right?
>
>
> Cheers,
> - Andreas
>
Mth
More information about the Squeak-dev
mailing list
|