constellation: Simplify the scheduler so it doesn't create a thread for each event

[emilio]

Thank you for contributing to Servo! Please replace each [ ] by [X] when the step is complete, and replace __ with appropriate data:

• ./mach build -d does not report any errors
• ./mach test-tidy --faster does not report any errors
• These changes fix #11268

Either:

• These changes do not require tests because it's a refactoring

Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process.

---

This PR builds on top of #11272 (it couldn't be reopened because I pushed to the branch before doing it).

r? @asajeffrey

cc @metajack @pcwalton

Concretely:

@metajack: This uses an auxiliary thread to take care of timeouts. It's not optimal (optimal would be rust-lang/rfcs#962), but it's way better than anything we had, and the other option (passing the thread handle around and unpark() the thread when appropiate) wouldn't work across IPC.

---

This change is

[highfive]

Heads up! This PR modifies the following files:

• @asajeffrey: components/constellation/timer_scheduler.rs

[asajeffrey]

My completely untested implementation, for comparison: https://github.com/asajeffrey/servo/tree/scheduler-with-fewer-threads

[asajeffrey]

Some IRC discussion: http://logs.glob.uno/?c=mozilla%23servo&s=19+May+2016&e=19+May+2016#c433870

TL;DR (but really it's very short): I'm concerned that this code may deadlock, or at least block for an unbounded amount of time, due to a race condition. Fixing it (as far as we can see) requires spinning on an atomic, since there's no test-and-park primitive.

[asajeffrey]

My now-tested implementation: #11283.

[emilio]

To be clear, I'm fine landing any of both approaches. I think this one would be a bit easier to migrate if rust-lang/rfcs#962 is implemented, but that's not a huge concern.

On the other side, after reading the docs more carefully, I think the discussion we had on IRC was wrong. This can't make us sleep too much. The point @asajeffrey was making was that if we called timeout_thread.unpark() before the thread started to park, it will sleep the timeout before returning.

From the docs:

park: Blocks unless or until the current thread's token is made available. 

(notice the "unless" bit).

That would mean that the worst case for this is the unlikely case that we call unpark() when the timeout thread's unpark_timeout has already ended, and thus the next time it would return automatically (since the token is available).

This is not a problem for this implementation, since once the timeout is raised, we'll re-check times before checking that again, and block, so this becomes a no-op.

In fact, I think this can't even be the case, since mpsc::recv() uses park() checking an atomic flag internally.

[asajeffrey]

Ah, this makes life a lot easier, I'll try again with this semantics of park/unpark.

[highfive]

New code was committed to pull request.

[asajeffrey]

We decided to go for #11283.