Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>No, the thread pool isn't appropriate. The thread pool is really designed for "short tasks that require background processing," since the framework depends on the availability of thread pool threads, and long-running processes can exhaust the thread pool. </p> <p>Ftp transfers take a relatively long time (even with a reasonable timeout), so they aren't really a good fit. You <em>may</em> be able to get by using the thread pool, but you may also find yourself running into inexplicable bugs if you use it. It depends how much your application uses thread-pool dependent framework features (asynchronous delegates, etc.).</p> <p>The MSDN topic "<a href="http://msdn.microsoft.com/en-us/library/0ka9477y.aspx" rel="noreferrer">The Managed Thread Pool</a>" offers good guidelines for when <strong>not</strong> to use thread pool threads:</p> <blockquote> <p>There are several scenarios in which it is appropriate to create and manage your own threads instead of using thread pool threads: </p> <ul> <li>You require a foreground thread.</li> <li>You require a thread to have a particular priority.</li> <li>You have tasks that cause the thread to block for long periods of time. The thread pool has a maximum number of threads, so a large number of blocked thread pool threads might prevent tasks from starting.</li> <li>You need to place threads into a single-threaded apartment. All ThreadPool threads are in the multithreaded apartment.</li> <li>You need to have a stable identity associated with the thread, or to dedicate a thread to a task.</li> </ul> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload