Please prevent dependencies between CPS and this particular event queue implementation

[zevv]

Mornin' Disruptek,

Went through the code a bit, but I need to spend some more time to get into the details. One thing I'd like to propose: your current implementation kind of implies the use of the provided eventqueue which is used by all the tests and all, which also holds the bare essential thing to pump an continuation, the trampoline.

I'd like to propose to make a very explict split between the CPS part and the eventqueue part to make sure there will be no dependency creep of one single eventqueue/selector/whatever on the CPS implementation. We should be able to use and offer CPS building blocks with a pretty clean interface and put that on top of anything we want. So continuations know nothing of fds or timers or whatever is out there in the world, it's just the context itself.

[disruptek]

That was always my feeling also, but I got frustrated writing tests without a real dispatcher. I was a little annoyed that I had to add a dependency to get the behavior I wanted, and I'm sure that irritated you as well. 😉

If you PR a replacement dispatcher, then we can move this one out to its own package and we'll be assured that cps stands alone. This would make cps development much simpler and more reliable, and it would probably help promote novel dispatcher development as well.

[disruptek]

AFAICT, this has always been the case. Feel free to reopen if you discover otherwise.

[zevv]

yeah, it was just me not grokking your virtual floating Cont