Using current_runtime always spawns additional thread.

[luben]

Running the single_threaded example spawns additional thread (though it is supposed to show that it does not need more threads):

$ ps -eLf | grep 'target/release/examples'
luben     1520 15628  1520  0    2 20:38 pts/18   00:00:00 ./target/release/examples/single_threaded
luben     1520 15628  1521  0    2 20:38 pts/18   00:00:00 ./target/release/examples/single_threaded
luben     1554 24569  1554  0    1 20:38 pts/19   00:00:00 grep --color=auto target/release/examples

My understanding is that the new thread is created by: https://github.com/hyperium/hyper/blob/master/src/server/tcp.rs#L32 but I may be wrong.

I have tried to go lower level using hyper::server::conn but was not able to create a truly single-threaded server. Please advice.

[seanmonstar]

Indeed, you are correct, I wrongly made use of Handle::current(), it should be Handle::default(). I just pushed a fix of this to master: 1d253b4

[carllerche]

Unfortunately, that API is a hazard that exists due to backwards compat... it should be improved in 0.2.

[seanmonstar]

@carllerche any reason to not deprecate it?

[carllerche]

@seanmonstar It is still useful to get a handle to the current reactor and not a lazy handle... but it is by far the minority case.

So, the question is how to reduce the hazard while still being able to access the functionality.

[carllerche]

Well, and Handle::current can start the global reactor... which was deprecated a while ago...

[seanmonstar]

Slap a #[deprecated] on Handle::current, and add Handle::current_or_background or something.

[carllerche]

I don't want anymore background ever :) I wonder if getting a handle to the current reactor should be a fn not on Handle.

reactor::current() or something.

[carllerche]

But yeah, I'd take a PR for deprecating Handle::current() at the very least... even w/o a replacement should be OK.