Michal Wallace <[EMAIL PROTECTED]> wrote: > On Fri, 16 Jan 2004, Dan Sugalski wrote: >> interrupts. Even if they aren't doing any IO at all they're still >> potentially watching for keyboard (or other OS-initiated) >> breaks/interrupts.
> I see your point. In python if you press ^C, it should > raise a KeyboardInterrupt exception. > But rather than always monitoring for that, I'd want > to register a listener Ehem: that's what we are talking about. There is a "listener" already running, that's the event thread. It currently doesn't much, but it "listens" eg for a timer event, that is, it waits on a condition. This doesn't take any CPU time during waiting except for a bit overhead, when the kernel awakens that thread and it executes (for a very short time). So this event thread sees: "Oh the kernel just noticed me, that the cookie for interpreter #5 is ready, so I'll tell that interpreter". That's what the event thread is doing. Now interpreter #5 - currently busy running in a tight loop - doesn't see that his cookie is ready. *If* this interpreter would check every pace, if there is a cookie, it would be a big slowdown. To minimze the overhead, the event thread throws a big piece of wood in front of the fast running interpreter #5, which finally, after a bit stumbling, realizes: "Oh, my cookie has arrived". > This is probably a dumb question but: what if signals > threw exceptions instead? We will (AFAIK) convert signals to events, which dispatch further. > I mean, they're pretty rare aren't they? Async is the problem. > Michal J Wallace leo
