Joachim Durchholz wrote:

> Eliot & Linda Miranda wrote:
> >
> > That's not the issue.  Squeak, and Smalltalk in general, _does_ have
> > green threads.  The issue is that the UI hasn't been written to be
> > multi-threaded.  And if one does make the UI multi-threaded then one
> > will have to consider what else in the system needs to be made thread
> > safe, e.g. compiling, adding/removing methods, etc, none of which is
> > currently thread safe.
> >
> > The current scheduling policy of being co-operative within a priority
> > means that UI developers have been able to ignore thorny thread safety
> >  issues.  This is one of the reasons the Squeak/Smalltalk UI has
> > evolved so fast and so interestingly. Think hard before you introduce
> > the complexity of a thread safe system.
>
> I understand this all. However, it makes the Squeak UI rather jerky (at
> least on my somewhat aged P-100 Wintel machine). Sometimes mouse clicks
> don't get accepted, sound playback gets horribly distorted if the user
> decides to scroll a large Window or do anything otherwise CPU-intensive
> in the GUI, etc. etc.

Its a common mistake, but the lack of responsiveness is not due to the threading model. Its due to the use of a polling user interface.  Squeak/Smalltalk-80 itself has an event driven queued I/O model at the lowest level.  See InputState.  There's a queue between the OS and Squeak, and all input events get put in this queue and none get lost.

Above this InputState and InputSensor maintain the current state of the mouse and maintain a queue of keyboard key presses.

At higher levels e.g. in MVC in Controller's controlActivity, controlLoop etc, controllers poll the current state of the mouse and consume keyboard events.  You may notice that although you loose mouse clicks you don't loose keyboard key presses.  This is because the mouse is polled, but keyboard events are taken from a queue.

Implementing a threaded GUI won't solve the lost mouse clicks problem; it's hard to say if it would make things better or worse, but it won't solve it.  The issue is that if the gui is polling the mouse then to recognize transitions in the mouse state the GUI has to poll at a frequency at least twice as high as the highest frequency one can toggle the mouse buttons.

The solution lies in implementing an event model for mouse clicks.  VisualWorks did this in VW 2.5 with a 65786 (<= humph, the cat just walked across the keyboard) with a filein called events.st.  In VW 3.0 we folded it into the base.  If mouse clicks are queued (and tagged with the position of the mouse at the time when the button was clicked) mouse clicks won't be lost.  But this does require a rewrite of the simple (and hence easily extensible) Controller polling loop.

[excuse me for not discussing Morphic; I've not had time to use it]

> It isn't the world, but I can't release anything
> built with it to current-day end users - they won't accept it, they're
> used to a system that accepts every mouse click immediately even if it
> doesn't process it immediately.
> I may have missed something - I'm just doing my first steps in Squeak.
> But it's frustrating (which adds to the frustration of having to find
> one's way through the class library).
>
> Regards,
> Joachim
> --

_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace