Impossible to both wait on a server and close it (all transports)

[faern]

The wait methods on the different servers are consuming self. Thus it's not possible to call close while waiting. This creates the problem that if you want to wait for a server to be able to instantly get notified of an error happening in it then you can't abort it before the entire process terminates.

Is this intended behavior or a missing feature? I always want to have a thread waiting for my servers, otherwise I can't detect if they have an error. But I also want to be able to shut them down whenever I want to.

[tomusdrw]

It's a missing feature, we never actually needed it yet (servers run as long as the entire process). Feel free to implement that though, probably a CloseHandle that can be returned by the Server would be a good idea.

[faern]

Yeah I was thinking about different solutions. And the different servers are implemented in very different ways, so different solutions might be suitable for different servers. But I guess you want the APIs of the different servers to be identical? Then maybe adding a pub fn close_handle(&self) -> CloseHandle to the Servers would be a nice solution.

Would you accept a PR adding that to only a subset of the servers? I'm currently only using the ws server and don't have the time to get familiar with all servers and fix them.

[faern]

Do you have to call wait on any of the servers to actually drive the event loop of that server? I see for ws that it spawns its own thread and the server will work perfectly without anyone ever calling wait. But is that true for all servers? That is a bit strange since it forces the user of ws to also spawn a thread to wait for the server, thus two OS threads are required to drive the server.

[faern]

How are the servers intended to be used? One can only call either wait or close. From your reply I take it that you only call wait? If so, is the Drop implementation really needed? No one will drop the servers anyway since they will live in a separate thread just idling in wait.

[tomusdrw]

1. I don't think it's good to leave the thread hanging without any handle if we don't implement Drop.
2. wait() was implemented to be used in simple examples where you spawn a server and then don't really want to close the main thread but rather wait for it indefinitely.
3. You can always create your own event loop and build server using a remote from that event loop. In such case you don't need two separate threads (it works this way for jsonrpc-tcp-server iirc).

The idea was:

• The user can spawn a server in one line.
• The spawned server doesn't block current thread when run.
• You can close the server by dropping the handle

Because each server used it's own separate event loop we abstracted it this way. For all tokio-based servers user should be able to choose if the new thread should be spawned or not.

I can see that it's definitely not perfect, I'm open to suggestions how to improve this. I'll accept a PR with this implemented for a single server.

[faern]

Another way to solve it so that all three bullets under "The idea was:" are preserved, and so the user does not have to spawn a thread, is to be able to provide an error callback closure to the ServerBuilder. That closure will get called in case the event loop exits with an error. This would be easy in ws where the event loop is simply a thread executing ws.run(), but it might be different for other servers. Not all of them return errors in their wait even. So servers that obviously can't error after they are started can simply not have this method on their builder.

[faern]

The CloseHandle approach looks pretty promising. Will test it out in my project before I submit a PR.

[rphmeier]

can this be closed now?

[tomusdrw]

It's only implemented for WS server, would be good to have it for other servers as well.