ipc: Allow specifying different event loop reactor in server builder

[Xanewok]

Right now we use Handle::default() (which should lazily bind to a reactor) when creating an IpcConnection but that surprisingly doesn't work with either the user-specified executor or the lazily spawned pool as the fallback executor on Windows (only tested on Windows 10).

Using a simple Runtime::reactor works, so to work around the issue I'd like be able to specify a custom reactor to be used (which seems somewhat useful on its own, hopefully).

Disclaimer: I'm not yet well versed in the async-fu so I might be missing something obvious here, please correct me if I'm wrong.

[parity-cla-bot]

It looks like @Xanewok hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

[Xanewok]

[clabot:check]

[parity-cla-bot]

It looks like @Xanewok signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[tomusdrw]

Yeah, the way we integrate between tokio and tokio-core and old-async is pretty messy now, see #425 .
If this solves some issues for you, let's merge it.

[Xanewok]

Yeah, it seems that named pipes require a consistent thread for the wakeups (cc NikVolf/tokio-named-pipes#2 and @c0gent who authored the change) so it seems necessary to be able to provide a user-specified handle.

Not sure if this changes semantics as we now construct Handle::default() outside the lazily spawned future now (tokio-rs/tokio#307)

The difference is that Handle::default will use the global reactor if called from outside of a runtime. This global reactor will most likely go away in 0.2 and was from pre Runtime.

I can use Option<Handle> for ServerBuilder::reactor and then inside the future use

let reactor = self.reactor.unwrap_or_else(Handle::default);

to bring back the original behaviour in case user didn't override the previous default reactor.

[tomusdrw]

can use Option for ServerBuilder::reactor and then inside the future use..

@Xanewok yeah, that makes sense to me

[Xanewok]

Done, added a comment why we need to create a default value inside a future

[Xanewok]

test transports::http::tests::handles_connection_refused_error ...
test transports::http::tests::handles_connection_refused_error has been running for over 60 seconds

that's unfortunate (also happened in #460 (comment))