Stephen Pair <stephen at pairhome.net> wrote:

>  - process safety issues - as you mentioned before, you want event 
> notification to happen asynchronously...if you push these events to the 
> end of some process, and the process is long running, you end up with 
> non-responsive UIs (i.e., a process takes 5 minutes run, you want to use 
> events to observe its progress and display a progress bar, events pile 
> up and are pushed to the end of the process, progress bar starts at 0%, 
> stays there for 5 minutes, then instantly jumps to 100%)...to alleviate 
> that, you start processing the events in background processes...now you 
> get into process safety issues (which is not a fault of the event scheme 
> itself, but of the overall lack of process safety in the system).

This is fascinating stuff.  Please just let me ask that things *not*
happen in separate threads by default.  Non-responsive UI's are not a
big problem in practice, once people are used to the idea that their
code should be event-driven and should release control in a constant
time.  It is MUCH easier, as you know, to manually put the handful of
expensive cases into background threads, than it is to allow everything
to happen in parallel and try to avoid every possible race condition.

To put it another way, perfect programmers don't care whether you
single-thread the event handlers together, so look at the difference for
imperfect programmers.  In a single-threaded system, imperfect
programmers will create laggy UI's.  In a thread-per-event system,
imperfect programmers will create crash-prone UI's.  Which poison is
better: laggy or crash-prone?

There is an interesting blend that I think people may be talking about:
a "co-routine" style, where there are certain methods that are allowed
to suspend the process until they return.  For example, Squeak works
this way right now for menus: when you call #startUp on a menu, the
Morphic loop continues on its merry way until the menu is finished. 
This style is a nice combination of the approaches: it avoids lagginess
while greatly limiting the number of places where race conditions can be
a problem.  However, I'm still not certain that this is better *in the
long run* than simple event-driven code.  A good programmer will
eventually want to put checks after every yield point, to make sure that
the world is still in a sane state for the activity that is being
performed.  For example, if the code will want to check that the
relevant windows are still open!  These checks aren't necessarily
simpler than the annoying code in event-driven code that restores all
your state.  Further, once the checks are added, the simplicity of the
code is going to decrease a good bit.  It sounds promissing on the
whole, but it's not as wonderful as it sounds up front.



Lex


PS -- I missed the begining of this thread, but I have code (a type
inferencer) that would *love* to get notified whenever the system
code is updated.  Anyone who implements it would have a very quick client!