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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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.... . 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project