Consider providing fn to retrieve a Handle for the currently running reactor Core

[carllerche]

Something like:

fn current_reactor() -> Option<&Handle> {
   ...
}

[alexcrichton]

Ok @carllerche, @aturon, and I talked about this at lunch today, and here are some of the thoughts we came up with:

• We should investigate the possibility of removing the distinction between Remote and Handle. This will require support at the mio layer to support concurrent registration of I/O objects, but otherwise this may be plausible. Not sure if this can be done though.
• It's a pain passing handles around everywhere currently (@aturon edit: previously said "tasks")
• It can be limiting to not pass a handle around depending on what the implicit behavior is
• One option is to have a thread local Handle and remove the &Handle argument from all functions. This would be configured early on in programs for the main thread and all functions would otherwise implicitly access this thread-local handle, panicking if it's not set. The downside of this is that if you attempt to make an I/O object on a thread pool it'll panic whereas today it wouldn't compile. Note that this solution still stores Remote (or the equivalent) in I/O objects, so this only affects their creation.
• Another possibility is to set a task-local Remote. This task-local is then inherited by default in spawned tasks. That way this by default covers more cases than the thread-local Handle but still has a few panics possible.

In general we found it difficult to reason about a global event loop and we didn't make too much progress along that front in figuring out what to do.

[tomyan]

@alexcrichton I came to this after looking at hyperium/hyper#1075. I was wondering if there could be a default event loop in order to make setting up a hyper server easy without needing to make it own the core and event loop - i.e. make the three steps I mentioned in that ticket two: set up the protocol/event handlers and then start the default event loop.

The way I'd imagine setting up event loops would be either a simple single threaded program with a single event loop, or a multi-threaded program with an event loop per thread: with event driven programming I generally expect the event loop to be running continuously for the duration of the program/process/thread (maybe this is because I've done a lot of JavaScript where all you have is the default event loop and there is no possibility of stopping it). If this makes sense, would it be possible to provide a way to get a thread local default core?

Thanks

Tom

[alexcrichton]

Thanks for the comment @tomyan! FWIW there's a comment which shows how to use Hyper with a custom Core if you're interested in getting that working today.

In general though in tokio-core we're hoping to avoid having a global event loop as it brings quite a few complications along with it. I believe there's crates like tk-easyloop which aim to provide this sort of "global" and/or thread-local access to a local event loop, and maybe those would help?

[tomyan]

Thanks for the pointer, I hadn't realised I could actually use that code. I was working on a PR for a default core and handle based on the code in #203, so I've finished and submitted that. Understand from your comment that it's unlikely to be accepted, which is fine but thought I'd submit for consideration anyway: #212. Interested in what kind of complications this adds, since from my perspective it makes the common case a bit simpler. Happy either way though, since the comment you pointed me to unblocks me.

Thanks

Tom

[alexcrichton]

Ok! I'll take a look at the PR

[surajprak]

This will be useful feature, any idea when it will be done?

[carllerche]

This crate is deprecated in favor of http://github.com/tokio-rs/tokio. New features are no longer being added. This feature is also provided in the new crate.