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: [email protected] [mailto:[email protected]] 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
