Working on yet another Rust async runtime, mostly because I'm annoyed by runtimes that are all tied to globals and want to see if we can do it handles passed as function arguments
-
-
I guess I should elaborate that I'm not opposed to globals in general, just to interfaces that leak the global-ness. I think futures-timer is a great example of this done well; it uses a global background thread to manage the list of queued timers and send wakeups as needed.
-
This is great because the interface is just "create a future that completes at a certain time / after a certain timeout". It's seamlessly compatible with any runtime, and now you can create timeouting futures through simple composition via Select.
- 5 more replies
New conversation -
-
-
It's a runtime compatibility thing; if all the runtime functionality is enabled via function parameters (for instance, a (trait-based) parameter for spawning tasks), then the discussions about "which runtime" go out the window, because you just use what you're given.
-
As an impractical but demonstrative example, anyone could make a simple HTTP server that takes a "&TCPAcceptor" parameter, where TCPAcceptor is a hypothetical trait that runtimes can implement.
- 1 more reply
New conversation -
-
-
My philosophy is: 1. the reactor is a global resource, much like stdin, so it can be global 2. the blocking pool is just an optimization over thread::spawn() for quick thread reuse, so no reason not to be global
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.