On Fri, 16 Jan 2004, Dan Sugalski wrote: > >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.
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 and then have parrot handle the polling for me. Maybe by default, parrot does the check every N instructions... And then you could turn that off if you wanted more speed. > 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. This is probably a dumb question but: what if signals threw exceptions instead? I mean, they're pretty rare aren't they? They seem like a completely different kind of thing than watching a mouse or socket... Different because signals have nothing to do with the program itself but come entire from the outside. (Whereas with the regular events, the data comes from outside but the choice to listen for the data was made inside the program.) Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --------------------------------------
