From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e7151167e0767ecc X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews2.google.com!not-for-mail From: wojtek@power.com.pl (Wojtek Narczynski) Newsgroups: comp.lang.ada Subject: Re: State Threads Date: 7 Sep 2004 08:20:36 -0700 Organization: http://groups.google.com Message-ID: <5ad0dd8a.0409070720.4026fb02@posting.google.com> References: <8429999a.0408231027.2850e800@posting.google.com> <5ad0dd8a.0409040738.3fff41b8@posting.google.com> <5ad0dd8a.0409060515.4b17e2ed@posting.google.com> <5ad0dd8a.0409061024.7c8831fd@posting.google.com> NNTP-Posting-Host: 83.27.58.81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1094570436 716 127.0.0.1 (7 Sep 2004 15:20:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Sep 2004 15:20:36 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:3434 Date: 2004-09-07T08:20:36-07:00 List-Id: Hello, > One (very old) way of doing this is the way it has tradionally been > done in TP monitors. (...) Gray & Reuter 'Transaction processing: concepts and techniques' is one of my favourite tech books. > On a Unix system the select or poll system calls would be the > natural choiche to handle your sockets, although I wonder how it would > scale to 100K connections. They would not, this is why xBSD has kqueue and Linux has epoll. > Also observe that the state-threads library has no explicit > support for multiple CPU's. Observed, need to fork one process per CPU. > You might argue that in a typical web server, each new request will > result in blocking disk IO, thus leading to an ever increasing number > of threads. But the answer is, just don't increase the number of > threads. If the disk is the bottleneck, increasing the number of > active requests will not give you any better throughput as long as you > have a reasonable number of active entries in the disk queue at any > time. In the application, we're looking at writing, there is no disk IO at all, there are only TCP and UDP conversations. But I think I could have a separate, internally threaded, file server process. BTW, Linux 2.6 can do asynchronous disk IO, after all these years... Currently I am attempting to renovate fsu threading, as I described in anoter other post. I'm stuck with assembly code, bleh! If this fails, I will re-read the G&R book on TP monitor architecture. Thanks, Wojtek