#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