Avoid creating a thread every single event we receive

[emilio]

We're doing this right now, for some reason I can't understand. We spawn a single thread just to sleep, ensure we're not cancelled, and send an empty message.

If we're going to use threads, we should at least use a thread pool, but probably there's a smarter way to do this, like a single thread that sleeps just the necessary time to dispatch the next event, or something.

I plan to take a look at this, but my time is actually constrained a lot, so if someone wants to investigate and refactor this, please do!

[asajeffrey]

I think I can see how to do this fairly easily: we have a dedicated thread for the event queue, which parks itself, then when it is unparked looks to see if the head of the queue is in the past, and if so pops and triggers it, then goes back to being parked. To schedule an event, we just add it to the event queue (in time order) and if we added to the front of the queue, unpark the queue thread.

Should be a reasonably straightforward use of thread parking and a priority queue, the tricky bit is going to be understanding the current API and if anything depends on the current behaviour.