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