Dan Sugalski wrote:
> At 10:33 AM -0700 5/11/04, chromatic wrote:
> >On Tue, 2004-05-11 at 10:24, Dan Sugalski wrote:
> >
> >> >I'm also curious how to write an interface to an
> existing event system.
> >> >Being able to write it all in PASM is a bonus.
> >>
> >> I don't think it can be all-PASM, except maybe (and maybe not...)
> >> with a separate thread for the existing event source. To
> do it in all
> >> pasm means calling back into parrot from interrupt level,
> which isn't
> >> really doable, or have a thread just waiting on events from the
> >> alternate event system to post into the parrot event queue.
> >
> >Another approach may be to expose the PollEvent and
> WaitEvent functions
> >to the event system as alternate sources of events. If I can do that
> >from PASM, I think I'm okay.
>
> That'll still need some C. The event system as it stands is all
> active--all event sources put events into the system, rather than
> having the event system go looking at event sources for events. You'd
> either need to queue up regular timer events to go check for new
> stuff or have a thread actively polling the source for events and
> throwing them into parrot's event queue.
What's the plan for integrating with system events, then? Mac OS X and
Windows both have robust, irreplacable, system-managed event loops.
parrot's loop can (and should) run in a parallel thread to those, but
certainly can't presume to take over entirely. It simply can't work.
If you're calling this an event system, it ought to mesh in with the
notion of events that every programmer who uses them will have:
- Mouse events.
- Keyboard events.
- Redraw events.
- Drag-'n'-drop events.
- Menu command events.
- etc., etc., etc..
Problems in this domain also include: Focus management, propagation
along the responder chain, enabling/disabling commands, default event
handlers.
You won't get any of these events from an I/O wait on Win32 or on a Mac;
they're not even delivered via Unix I/O. Note that the thread on which
these events must be handled is the thread to which they are delivered
(and not by parrot's event loop): UI APIs are not thread-safe. So the UI
thread needs to be able to enter a parrot callback on the same thread.
Asynchronous I/O completion is surely considered less of an
event-handling problem and more of a thread-synchronization problem.
Also, parrot async I/O completion hopefully won't need to be serialized
through an I/O retirement thread ("event loop," whatever you want to
call it) except when the platform winds up requiring that through sloppy
async APIs.
This is really an asynchronous notification API, where asynchronous
completion is a very important "fires-once" form of asynchronous
notification. It's far, far below what programmers will expect when
hearing the term "event."
.NET's thread pool is a very close match to what you're discussing. A
.NET "WaitHandle" is almost identical to your event source. (Right down
to the waitone/waitany ops you just suggested.)
The intuitive concept of "events" isn't even in the same class of
problem that your document addresses. Probably best to use another term
for this (very cool, very necessary) technology.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
P.S. - Now that they're in, have you considered using objects and
methods instead of opcodes to define parrot APIs? If parrot technologies
are exposed through objects, you'll save on opcount, and HLLs won't need
to build yet another a shim for every new parrot feature. Dogfood.
