Stef, Gary, Having recently ranted a little about thread safety for weak collection, how can I argue? Well, let me see if I can do so and keep my credibility intact :) Squeak's weak collections, and we have not moved beyond their limitations, do not clean themselves after their elements are finalized. That means they do half of what they should do; once they do all of it, they need to be thread safe; hence they do one third of what they should do. The GUI is arguably a little different. #addDeferredUIMessage: provides a clean way to interact with it from background threads, and that might be enough. IDE specific messages (e.g. #inspect) could probably stand to be queued to make them safe w/o horrible penalties, with the remainder of the GUI understood not to be thread safe for performance reasons. A backround thread can do expensive calculations and then queue a GUI update to safely update the display. 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: Monday, November 02, 2009 3:28 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: MouseOverHandler Hi gary do you think that it make sense to have it in general (my gut feeling is saying yes but I'm not thread-safe) If yes, yes we are interested for 1.1 BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming. Stef On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote:
Yet the cause is unexplained. I still think it is due to non-ui processes fiddling with morphs (likely delettion or creation). The Morphic event loop remains non-thread safe. We have some modifications to ensure thread safety, based on a generalised synchronisation protocol if anyone is interested.
Regards, Gary ----- Original Message ----- From: Hernan Wilkinson To: Pharo-project@lists.gforge.inria.fr Sent: Monday, November 02, 2009 7:45 PM Subject: Re: [Pharo-project] Fwd: MouseOverHandler
Hi Adrian, the current implementation has problems, ie. send messages to nil, and it bothers a lot when that happens because it comes from nowhere... I've been using this implementation for a long time in my images and I did not get those problems anymore (and it is more readable...)
On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi@netstyle.ch> wrote: Hi Hernan,
The reason this was not integrated is that nobody marked it as 'fixed' nor tagged it as 1.0.
Is this critical for 1.0?
Cheers, Adrian
BTW, if anybody sees changes/fixes not being integrated please ask on the mailing list.
On Oct 31, 2009, at 14:29 , Stéphane Ducasse wrote:
Begin forwarded message:
From: Hernan Wilkinson <hernan.wilkinson@gmail.com> Date: October 29, 2009 2:02:32 PM GMT+01:00 To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: MouseOverHandler
Hi Stef, do you know why the MouseOverHandler version I made is not in the main image? the current version is not working well, under heavy use it generates exceptions... I'm attaching the version I wrote that I'm using without
problem...
Hernan.
<MouseOverHandler.st>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project