Dan Sugalski <[EMAIL PROTECTED]> wrote:An unsolicited event, on the other hand, is one that parrot generates as the result of something happening external to itself, or as the result of some recurring event happening. Signals and GUI events, for example, are unsolicted as are recurring timer events.
I don't think that there is much difference between these two types of events. You don't get signals if you don't do the appropriate sigaction call. You ask the OS for an one-shot timer or for a recurring one, so you'll get one or more events. That's all known.
The difference there is that a solicited event is one you have asked for *and* received an event/request object for, so you can identify the request/event as it makes its way through a stream. You can't do that with the unsolicited ones, since you don't know they exist until they've shown up.
I think I need to make clearer the difference between events and event sources, since that's a source of confusion with Uri too.
> There are four big differences between solicited and unsolicitedevents:
That's adding some unneeded restrictions IMHO.
Then it needs some more explanation, since they're not so much restrictions as statements of fact which fall out of the design.
> 3) A solicited event may have a callback and user data associatedwith it, an unsolicited event may not.
E.g. this looks like that you can't run a user handler on a repeated timer.
That's one of the things that's missing. You can, but only in a general sense--that is, you can have a handler that is run for every event of a particular class, and since timers are a class, well... there you go.
> IO Ops
Uri did already comment on seek/tell. Some of the *handler ops probably need some more explanation.
Yep, there's a lot that needs fleshing out, but I figured a first draft of the skeleton would be worthwhile. Working on draft 2.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
