How can I know when a thread is ended?

I am sifting through a lot of documentation returned by searching online, but still would appreciate if someone can point me in the right direction:

I want to create an application that will use multiple threads, where each thread maintains a connection to a network client.

I want to cap how many threads are created.

If a connection is dropped / the thread ends, how is this signaled back so that I know that a new thread can be created?

 

You could create your own event. However, since the connection being dropped/ending is also indicative of you wanting to end the thread and be able to create a new one, you could use that.

However, that being said, if you didn't already know.. there's no reason to have a thread per connection (perhaps the best wording would be : "Could very well be no need to have.. etc").

 

Thanks methos5k.

Regarding threading and my use case: each connection would be active, consistently. The game server / Unity app would communicate multiple times a second to each client. My idea is that it would be more efficient if each connection were just maintained, versus having to establish a new request for each transaction. I would cap the number of threads = how many clients that can be supported, to reduce impact on the server side as much as possible. But if a client dies, I want the thread / connection to be freed to accept a new client.

 

Okay, well I can understand wanting to maintain the connection (tcp) -- one thread can handle many connections, though. In fact, as you noted, too many threads can become bad/not useful.

Better to use threads for: main thread, connections, long tasks, etc.. (that kind of division vs per user). Just my 2 cents

 

Not sure if this would work optimally for you but I tend to use the ThreadPool as opposed to 'new Thread(/*Things*/)'.
I know it is not the point necessarily of this forum thread but may be useful for performance as it handles the threads for you when it comes to too many threads being bad for performance.

https://msdn.microsoft.com/en-us/library/kbf0f1ct(v=vs.110).aspx

Code (CSharp):

1. // Works like so:
2.  
3. // Add to queue
4. ThreadPool.QueueUserWorkItem(MyFunction);
5.  
6. public void MyFunction(object state)
7. {
8.     // Do things
9. }

 

Do NOT create a new thread for every connected client. That is a very very bad way to manage the connections. At most, have one thread for managing networking. CPUs aren't magic, they can only multitask by as many cores they have. Once the number of threads is beyond the number of cores you will get diminishing returns (well, not entirely true but I'm not going into hyperthreading...).

By the way, threads have a property called ThreadState, which will tell you if it has started/stopped.

 

Came in here to post pretty much the same thing. Don't forget the OS itself still needs one or two threads

Honestly, for network connections, you don't need to make a thread for each connection. That's overkill. It wouldn't even work all that well anyway, since typically you'd want to receive packets (at the UdpClient level) on a port, then handle it based on where it came from.

If it's something that requires a long running task, that's where it makes sense to stick it into a "thread" from the pool, so you don't block the UDP receiver from receiving new messages from other clients.