-
Notifications
You must be signed in to change notification settings - Fork 83
with_handle NewService lifetime overly restrictive? #182
Comments
I'm having the same issue and came to the same conclusion by looking at TcpServer code. |
I hit this too and came to the same conclusion - removing Send + Sync bounds seems like the right fix to me (i.e. as #183 shows), and is what I'm running with for my development at present. |
It is required to be That aid, as a result of the Tokio reform RFC. tokio-proto is going to be significantly simplified and focus more on getting started than provide a full blown solution to all cases. Odds are, in this case, a multi threaded server will be out of scope or at least decoupled in a way to not impose this bound. |
What do you mean by "in order to support multi threading"? As I said, a |
I'll cc @aturon as IIRC, he lead the effort for this bit of the code. |
https://github.com/alex/ct-tools/blob/master/src/main.rs#L315-L410 is the code I implemented/copy-pasted from tokio-proto to accomplish what I was after, FWIW |
https://github.com/tokio-rs/tokio-proto/blob/master/src/tcp_server.rs#L106-L115
Currently the
NewService
instance returned byF
must beSend + Sync
. Is this necessary? My read of the code is that a distinctNewService
instance is created for each thread, and never moved from the thread. (https://github.com/tokio-rs/tokio-proto/blob/master/src/tcp_server.rs#L184-L186)The result of this lifetime is that actually using the
handle
is difficult. For example, the following code doesn't work because the closed overhandle
is notSync
:My impression is that this type of use case is what was
with_handle
was intended for.I was able to work around this with the completely insane:
which seems to confirm that everything is on the same thread.
At a minimum, better documentation of this pattern seems valuable.
The text was updated successfully, but these errors were encountered: