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.
Well, it could work, but it'd take an awful lot of effort and it's possibly a bad idea. Or... not.
But yes, we may be stuck with two event loops (or a master/slave loop setup) in some places.
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..
And it does. Or, rather, it can, and it will many places, though not all of them, unfortunately.
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.
That's not necessarily true, actually, at least not for OS X. (I can't speak for Win32)
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."
Well... maybe. For many programmers it's dead-on what they're expecting. If you're writing server or console code, or dealing with quite a number of the 'cross-platform' GUI APIs, it's exactly what people expect. For Win32 and OS X programming, it's less so, but in that case you have to give yourself over to the local event loop. *Something* has to run the show, and in that case it's pretty clear that it has to be the OS' event loop.
There is a reasonably simple way around this (And with a bit of trickery I could do it for OS X) which is to have the OS callbacks do nothing but post events into Parrot's event queue and leave it to parrot to then manage the (now local) events and do all the Clever Things that your average GUI program needs to do. Whether this is feasible or not is somewhat up in the air, though. (Objective-C makes this easy. Can't say how it works other places)
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.
I think that very much depends on both the system you're working on and your concept of events.
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.
I have, but I don't really want to pay the overhead, and since there are enough shims that'll have to be in place as it is I'm not too concerned. Once you're past three or four you just end up building a general-purpose table-driven translator to sort out what's an op, what's a sub, and what's a method on an object. (Well, OK, you don't have to, but then things get hellish pretty quickly)
OTOH it's probably about time for me to get over my dislike of objects and just deal with it. Timers'd be a good place to start, I suppose.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
