You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an awesome project, it's really helped me understand the mechanics of futures better! Thank you!
One thing I haven't quite wrapped my head around is why we need any sort of global REACTOR. Each task is polled from an EventLoop - and indeed we're already passing the EventLoop instance up the stack in the guise of a Handle (er... a Spawn, which of course can't be down-casted), as part of the Context. It seems very awkward to require using global state, when we have all the state we need, already passed around to the proper places through a Context object (just inaccessible ☹️).
It seems it would be much cleaner to be able to down-cast some part of the Context in order to call add_read_interest in the "leaf" Future implementations (like AsyncTcpStream). This would of course require a change to the Context API.
Thoughts?
The text was updated successfully, but these errors were encountered:
This is an awesome project, it's really helped me understand the mechanics of futures better! Thank you!
One thing I haven't quite wrapped my head around is why we need any sort of global☹️ ).
REACTOR
. Each task is polled from an EventLoop - and indeed we're already passing the EventLoop instance up the stack in the guise of aHandle
(er... aSpawn
, which of course can't be down-casted), as part of theContext
. It seems very awkward to require using global state, when we have all the state we need, already passed around to the proper places through aContext
object (just inaccessibleIt seems it would be much cleaner to be able to down-cast some part of the
Context
in order to calladd_read_interest
in the "leaf" Future implementations (likeAsyncTcpStream
). This would of course require a change to theContext
API.Thoughts?
The text was updated successfully, but these errors were encountered: