It's probably going to be heavily based on smol. I was inspired by @stjepang's simple and straightforward design and wanted to see if I could carry it even farther forward, getting rid of globals entirely.
-
-
Replying to @Lucretiel @techpractical
Are you going to use thread-locals or getting rid of them also? I'm considering removing the global executor from smol so the only two globals would be: 1. the reactor 2. the blocking pool
1 reply 0 retweets 0 likes -
Replying to @stjepang @techpractical
Ideally no thread-locals, but we'll see what's possible. My ideal design has all the relevant resources (reactor, pool) live high in the stack (near main) and passed by reference parameter down into the actual async code, but I'm not sure if the lifetimes can be made to work
1 reply 0 retweets 0 likes -
Replying to @Lucretiel @techpractical
I see - my hunch is that Arcs will be needed to make this practical, but would love to be proven wrong! Btw, I wonder why you want to eliminate all globals?
3 replies 0 retweets 2 likes -
Replying to @stjepang @techpractical
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.
1 reply 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
Replying to @Lucretiel @techpractical
Makes sense, although I'm not sure I understood completely. Do you have examples of interfaces that leak globalness? Do you consider async-std's concept of global runtime "good" or "bad"?
1 reply 0 retweets 0 likes -
Replying to @stjepang @techpractical
So, suppose you had a server that consumed an API. Suppose that for whatever reason, you want to use async-std-based library for handling incoming connections, but a tokio-based library for handling outgoing connections.
1 reply 0 retweets 0 likes -
My understanding is that this doesn't work well, because they have their own reactors and both want to take control of `main` and want to control when blocking (ie, waiting for OS events) actually occurs.
1 reply 0 retweets 1 like -
In theory, there's no reason it couldn't work, though. You'd pay an efficiency penalty, but there's nothing preventing an application from having more than one epoll set up, and having different threads wait on them separately. That's what I mean by leaky globalness.
1 reply 0 retweets 1 like
I see - so by leaky globalness you mean "i need to do extra steps to make things work"? So in that sense tokio is leaking, but async-std isn't - is my understanding correct?
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.