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!news1.google.com!news.glorb.com!newsfeed00.sul.t-online.de!t-online.de!inka.de!rz.uni-karlsruhe.de!news.uni-stuttgart.de!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: State Threads Date: 07 Sep 2004 12:08:57 +0200 Organization: Sun Microsystems Message-ID: References: <8429999a.0408231027.2850e800@posting.google.com> <5ad0dd8a.0408302222.56282d6f@posting.google.com> <4135498c_1@news.tm.net.my> <5ad0dd8a.0409040738.3fff41b8@posting.google.com> <5ad0dd8a.0409060515.4b17e2ed@posting.google.com> <5ad0dd8a.0409061024.7c8831fd@posting.google.com> NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1094551739 27479 129.159.112.195 (7 Sep 2004 10:08:59 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 7 Sep 2004 10:08:59 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3427 Date: 2004-09-07T10:08:59+00:00 List-Id: >>>>> "WN" == Wojtek Narczynski writes: WN> Hello, >> I've seen plenty of information and indication that C does not >> outperform Ada significantly or at all. WN> You merely scratch the subject. How exactly would you structure an Ada WN> application to handle 100K socket connections? One (very old) way of doing this is the way it has tradionally been done in TP monitors. You have a pool of servers for each server class. In case you only want to have a web server, you just need one pool. The number of servers (threads) are dependent on you number of CPU's. Typically you want some more threads than CPU's to account for threads that may be blocking on IO. If you want to be fancy (TP systems are), you can include a load balancer which creates new server threads in case some of you CPU's are idle although there are unprocessed messages, otherwise just have a reasonable number of threads in reserve. All threads are identical, and execute in an endless loop, consuming messages from the network. When the message is read, the thread restores the execution context, in a TP system it would be the transaction state, in a web server it would be the session state. It then dispatches on the message type, and executes in the restored context. When it is finished, it sends the result. This model has no problems with blocking on disk IO, because if a thread needs to block, it blocks, and some other thread gets to execute. As long as there are enough threads, no CPU will be idle. Since we dimension the number of threads after the number of CPU's not after the number of connections, there should be no thrashing. Now, this model is probably closer to an event driven model than you like, but you do not need to register any callbacks. The two critical points with this scheme are fast retrieval of messages from the network and fast restoration of the execution context. 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. The execution context takes the place of the stack in state-threads, whether one is better than the other depends on the application, I would think. Also observe that the state-threads library has no explicit support for multiple CPU's. 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. >>> Also disappointing is the NIH syndrome that prevails the Ada world. >> No. We may be keen on 100% Ada, 0% bugs, but will use a good binding >> happily. GtkAda, Pgsql... WN> Mercy. Without non-Ada code you could not even boot your computer, so WN> you are forced to use non-Ada code, it's not your choice. WN> Besides, this NIH syndrome is about reusing concepts, not about WN> reusing code. WN> Regards, WN> Wojtek -- C++: The power, elegance and simplicity of a hand grenade.