The example looks very strange to me. Why test the against the active process? Threads are useful because they let us forget about such things: just fork the work at a background priority and let the scheduler handle it - add no small amount of attention to synchronization, of course. I tend to overprotect, so the most common problems I need to find are deadlocks, and they show themselves fairly easily given at tool that shows all callstacks.
I have a lot of code that uses #forkAt: and expects to get the process, so I am probably not the most neutral party in this debate.
Bill
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Saturday, July 18, 2009 4:58 AM
To: An open mailing list to discuss any topics related to an open-source Smalltalk
Subject: [Pharo-project] fork cleaning in CUIS
2009/7/17 Andreas Raab <andreas.raab <at> gmx.de>:
> Juan Vuletich wrote:
>>
>> Some might remember
>>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/124960.html >> . It was a discussion about the dangers of using the result of #fork and >> friends, and the convenience of first creating the process, storing it >> somewhere and later doing #resume. In this release of Cuis, all callers of >> #fork and friends that needed the return value were changed for that >> pattern, and now #fork and friends simply return nil. This is the way to >> avoid those nasty bugs.
>
> I really like that solution. It's simple and ensures people know what > they're doing.
>
+1
Good to know that someone put that discussion fruits into a practical plane, even if in own fork :)
> Cheers,
> - Andreas
>
>
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
