The point of the interface the backend/callback stuff is that it shouldn't block on waiting for _i/o_ on one fd while there's i/o possible on other fd:s. The point is to coordinate the i/o blocking for all fd:s. And perhaps signals (although it would be nicer if it didn't have to do that). No more, no less.
When possible, it should be robust to stupidity outside of the process itself (such as stdin being shared with other processes). That you can do arbitrarily stupid things *within* a particular callback function for a particular file is not relevant for the backend machinery.
I think this discussion is getting stupid. Sure, If you feel like implementing a check that emits some kind of warning if sleep is called inside a read callback, go ahead, I'll probably not object, but that is a different issue.
/ Niels Möller ()
Previous text:
2003-03-19 15:38: Subject: I/O callbacks in blocking mode
Here's a read callback that will block the backend for an hour:
void my_read_callback(string data) { sleep(3600); }
Horrible. How should we change the language to ensure that this program is impossible to write? Who cares if we break a lot of legitimate programs, as long as we fix this terrible "bug" in the backend?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)