Subj : Re: dynamic allocation, deallocation but not heap fragmentation! To : comp.programming.threads From : doug Date : Tue May 17 2005 12:26 am "David Schwartz" wrote in message news:d65ejc$jd4$1@nntp.webmaster.com... > > "jimjim" wrote in message > news:fRkhe.31770$G8.20390@text.news.blueyonder.co.uk... > >> Or, did you mean I can have a fixed number of threads and queue up >> somehow client requests? How can I choose how many threads I need in this >> way? > > It's not difficult to compute the number of threads. You need: > > 1) One thread for each CPU you need to keep busy. > > 2) One thread for each quick I/O that must be blocking that you can > usefully do at the same time. (This is typically 5 or 6.) > > 3) One thread for each long-term I/O that must be blocking. (You > usually don't have any of these, but sometimes you can't avoid it.) > > 4) One thread for each special job that really needs its own thread. > (For example, one thread to wait for signals, maybe one thread to kick off > timed events, and so on.) > > And that's it, unless I forgot something. > > So when a client makes a request, add it to a linked list of requests > and signal a condition variable. When a thread has nothing else to do, it > pulls the head request off the linked list or blocks on the condition > variable if there are no requests. You can dynamically adjust the number > of threads if you really need to. > > DS > > Hi all. My reader is playing up and I can't see the discussion you talk about - the one about the per-connection vs threadpool debate. Any chance you can give me the highlights - the great punches thrown, etc., and who came out on top in the end? Any good references/links? Does anyone know what the industry standard bods (Apache, IIS, MySQL, etc.) do here? I might have a scan in the morning... btw, there's an interesting way to do cleanup stuff with pthreads - you can register a cleanup routine with pthread_cleanup_push. This is called when the thread exits, and this can do your mop-up. I tend not to use it myself, though, as it's a bit implementation specific, and poor sods who come along later to maintain the code (and aren't experienced with coding or the particular codebase) have no idea what's going on under the covers. Cheers, DOug .