Asynchrounous events

Lex Spoon lex at cc.gatech.edu
Sat Jul 10 19:50:48 UTC 1999


It's dangerous in the present system, as few things in Squeak are designed to be thread-safe.  Most threads in Squeak are very carefully designed so as to not mess with objects that the main UI thread might be using.  In fact, most objects belong to a specific thread, and when they are accessed by multiple threads, they are carefully designed to be robust under such treatment (for instance, the SharedQueue class).

I'd guess you aren't seeing errors right now because the threads aren't actually preempting other much or at all, because of the way squeak threads work.  But if you sprinkled some "Process yield"'s in there, or if some of the threads started doing socket requests, it could get hairy....

An alternate approach would be to make just certain events fire in separate threads, rather than all of them.  Handlers for such events would simply have to be careful.

Lex


"Peter Smet" <peter.smet at flinders.edu.au> wrote:
> After the previous discussion on the list, I finally got around to having a
> look at an asynchronous publish-subscribe mechanism. My understanding could
> be off here, but this may be as simple as changing
> changed: aParameter
>  stepA. stepB. stepetc...
> to:
> changed: aParameter
>  [stepA. stepB. stepetc...] forkAt: 3
> 
> I implemented something along these lines in my PostOffice mechanism, so
> that the event triggering mechanism forked off a new thread for each event
> that an Object generated. My initial (and probably wrong) impression is that
> this works quite well. Even forking at low priorities like 3, with a
> background process of other events running, things did not crash (naturally,
> responses were delayed). If you set the priority to 5,6,7 things appear as
> per normal. My testing used a few open CHBrowsers and file lists, which had
> their changed/update protocol implemented by the PostOffice. Admittedly this
> is not a very thorough test, and the key issue is where objects implement
> update: by sending enquiries back to the event publisher enquiring about
> status. If the publisher changes a lot between generating the event and
> getting the enquiry this will cause problems.
> 
> I would like to hear from others how dangerous asynchronous events are
> likely to be, and what sorts of things in Squeak rely on the updates: being
> completed before control returns to the event-generating object. Then I can
> run some more critical tests. Why am I doing this? I am still musing on the
> idea that publish-subscribe events can be put on the same queue as OS-level
> events.
> 
> Peter





More information about the Squeak-dev mailing list