James Y Knight wrote:
> On Jan 14, 2010, at 10:12 AM, Tobias C. Rittweiler wrote:
>>> I'm not particularly opposed to SLEEP calling DECODE-TIMEOUT to check
>>> for deadlines. (DECODE-TIMEOUT signals the deadline if it has already
>> Ok; DECODE-TIMEOUT won't take *PERIODIC-POLLING-FUNCTION* into account
>> but I _could_ live with it if at least deadlines are shot.
>> I'm not experienced with the serve-event framework, and how it
>> internally hooks into SBCL's I/O routines.
>> What additional surprises may there be when SLEEP does not hook into
> IMO serve-event should be shot into a million pieces. It's such a pain
> in the ass that it gets called implicitly all over the place. Adding
> more such places wouldn't make me any happier about it.
> I'd prefer an event loop facility to be only invoked explicitly and
> never recursively called within itself.
> The "additional surprises" you'll get with sleep not calling serve-
> event is that event handlers won't be called. I'm not sure I'd call
> that a surprise, though. :)
The event-loop code I've always seen (C/C++ heritage) follows a simple
pattern for sleeps: schedule a timer and tell it what to do (in CL,
lambda makes this easy). Blocking and event loops don't go together. A
true sleep would only be useful if you actually do want to block event
handling for a period.
As many have said before, recursive event loops are evil; they introduce
all sorts of multithreading-style issues, without most multithreading
benefits. I have fixed my share of obscure bugs in C++ caused by an event
loop recursing where it shouldn't. For example, event loop calls
select(), recurses when handling a read or write, recalls select, handles
everything else, returns, tries handling remaining events from first call