Question

I have a design question. I want some feedback to know if a ThreadPool is appropriate for the client program I am writing.

I am having a client running as a service processing database records. Each of these records contains connection information to external FTP sites [basically it is a queue of files to transfer]. A lot of them are to the same host, just moving different files. Therefore, I am grouping them together by host. I want to be able to create a new thread per host. I really don’t care when the transfers finish, they just need to do all the work (or try to do) they were assigned, and then terminate once they are finished, cleaning up all resources they used in the process.

I anticipate no more than 10-25 connections to be established. Once the transfer queue is empty, the program will simply wait until there are records in the queue again.

Is the ThreadPool a good candidate for this or should I use a different approach?

Edit: For the most part, this is the only significant custom application running on the server.

Answer 1

From what you have described, it sounds like the threadpool would be a good fit.

Issues:

1. A threadpool thread will not keep your process alive on shutdown. Make sure that’s the behavior you want.

2. In older reading, tying up the threadpool with long-runnign tasks when the app might be waiting on incomping connections (like a web app) could be bad. However, it sounds like you have a dedicated windows service running, so I don’t think this is an issue.

3. Just because you throw 10 jobs at the thread pool does not mean that it will immediately dispatch 10 threads to do the work — you are delegating the decision of how many threads to use to .net and the o/s.