On Fri, 16 Jan 2004, Dan Sugalski wrote:
2) Those that explicitly check for events...Ops like spin_in_event_loop (or whatever we call it) or checkevent is in category two. They check events because, well, that's what they're supposed to do. Compilers should emit these with some frequency, though it's arguable how frequent they ought to be.
I don't understand that part. Why the compiler?
Because we don't have the sort of control of the async environment that hardware does to deal with interrupts.
And, realistically, all code has to deal with the possibility of interrupts. Even if they aren't doing any IO at all they're still potentially watching for keyboard (or other OS-initiated) breaks/interrupts.
If the high-level code doesn't do anything with the events, then there's no point in checking. If it does use the events, then shouldn't developers call the even loop explicitly?
Well... There's the issue of signals, which is the big one. If we could skip signals, that'd be great, but we can't, even on systems that don't do them in the true Unix-y sense. Windows programs should respond to breaks from the keyboard (or close-window requests in a terminal-esque environment if we build one) and have a chance to shut down cleanly, so... that's an event.
--
Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk