Any consensus?

I see advantages and disadvantages to both.

For a socket listener, a background thread would be good I would imagine, if the server is attempting to close, it obviously does not need or want to accept connections and any connection that is in the process of starting should stop...immediately.

For a connected socket, my opinions vary. Background is good so that if a server is closing and has hundreds of threads (potentially) ending them all gracefully could take time, and if the server is running as a service, this could cause the service controller to have a fit because the service didn't end fast enough, but background threads would just stop. But it also causes havoc for the client(s) connected (maybe) and they wouldn't receive notification that the connection died until it timed out or a check was made by the client...

Anyone have any thoughts or opinions?

Recommended Answers

All 2 Replies

You run into the same problem on the server if they are background threads. Because they aren't closed (just ended) they leave the connection up until they timeout. If they are foreground threads then they block closing. You could attempt to close them and set a timeout to abort them if they haven't closed in time.

I don't believe there is a 'right' answer, it's how you want to deal with it. I would always make an attempt to stop all threads, no matter if they are foreground or background though.

Excellent point. My brain immediately thought "thread ends, socket closes" but that's not true.

I think the service controller aborts the service thread after 30 seconds doesn't it? When it receives the stop command I mean.

Guess it's best to try to close all threads, close all sockets and hope it finishes in 30 seconds. If not, doesn't really matter, the ports will stay open anyway until they timeout.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.