Stephan,

> However, I'd like to implement the new event stuff - at least 
> if it is what I except.  Even on an idle system, the current
> squeak runs and eats up CPU cycles.  Will events help here?

Not really. Only if ioRelinquishProcessorBlaBlaBla() is implemented
appropriately.

> Okay, so if events mean that you can get rid of Squeak's 
> polling loop, what does Squeak expect?  Is there any documentation?

The basic idea is that ioGetNextEvent() retrieves the next event. The event
types and structures are in sq.h; the fields need to be filled in
appropriately. But we can't really get rid of a polling loop - see below.

> I think, there're two important functions:  One to tell the 
> VM about a semaphore on which - I guess - the Smalltalk code
> will wait for the next event.  And another to retrieve that
> event from the VM.  The mac VM seems to allocate a circular
> buffer with 1024 elements to store elements.  However, I
> wonder why the code to signal the semaphore is 
> commented out.  Doesn't that means, the whole event stuff 
> doesn't work yet?

It works perfectly. The issue with the semaphore is a bit more complicated.
Since almost all VMs currently use a single thread for running both,
interpret() and the event processing loop, we have to be OUT OF INTERPRET()
in order to receive an event. This means that as long as none of the ioXYZ
functions is called (which may call some OS level function, which may in
turn return an event or call some callback) you will not receive any event
at all. Understood so far?!

The above basically implies that - given Squeak is running a tight byte code
loop in a single process - no events will ever be reported to it. This is
simply because none of the ioXYZ functions is called. There is one fallback
position which is that about every half a second the interpreter will
manually call ioProcessEvents() in order to determine if the interrupt key
was pressed. If the interpreter wouldn't do this, none of the ioXYZ
functions might ever be called.

In effect this means that - due to running both interpret() and the VM event
processing code in a single thread - the event process has to poll, simply
to make sure some ioXYZ function is called so that event processing goes on.
But since it does this, there is no real point in signaling the input
semaphore, eh?! Keep in mind that the code signaling the semaphore is most
likely being called from ioGetNextEvent() - it's usually something like:
-> ioProcess calls primGetNextEvent()
   -> ioGetNextEvent calls some OS specific function
   -> OS issues event callback
   -> event is recorded
   [this is the place where you would signal although you are already in
ioGetNextEvent]
   -> OS comes back to ioGetNextEvent
   -> ioGetNextEvent fills in the event you just signaled

The input semaphore is only useful if in fact the VM event processing loop
is running in a separate thread. In this case, it can signal the input
semaphore to announce that events are available.

While it does no harm to signal the input semaphore when a (synchronously
processed) event occurs it also doesn't really help (in fact it'll slow down
the system a bit since the event processing loop will go looking for an
event although it has already received the one that just got signaled).

> Which events (what kind of events) are raised?

See the event definitions in sq.h.

> And what's about sockets or serial port?  Are they still
> polled or will they also use events?

They're still polled. The key issue in the VM event stuff was not loose user
input events anymore.

Cheers,
  - Andreas