<br><div class="gmail_quote">2008/7/2 Perry E. Metzger &lt;<a href="mailto:perry@piermont.com">perry@piermont.com</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
&quot;Robert G. Brown&quot; &lt;<a href="mailto:rgb@phy.duke.edu">rgb@phy.duke.edu</a>&gt; writes:<br>
&gt;&gt; Well, it actually kind of is. Typically, a box in an HPC cluster is<br>
&gt;&gt; running stuff that&#39;s compute bound and who&#39;s primary job isn&#39;t serving<br>
&gt;&gt; vast numbers of teeny high latency requests. That&#39;s much more what a<br>
&gt;&gt; web server does. However...<br>
&gt;<br>
&gt; I&#39;d have to disagree. &nbsp;On some clusters, that is quite true. &nbsp;On others,<br>
&gt; it is very much not true, and whole markets of specialized network<br>
&gt; hardware that can manage vast numbers of teeny communications requests<br>
&gt; with acceptably low latency have come into being. &nbsp;And in between, there<br>
&gt; is, well, between, and TCP/IP at gigabit speeds is at least a contender<br>
&gt; for ways to fill it.<br>
<br>
I have to admit my experience here is limited. I&#39;ll take your word for<br>
it that there are systems where huge numbers of small, high latency<br>
requests are processed. (I thought that teeny stuff in HPC land was<br>
almost always where you brought in the low latency fabric and used<br>
specialized protocols, but...)<br>
<br>
&gt;&gt; Myself, I&#39;m a believer in event driven code. One thread, one core. All<br>
&gt;&gt; other concurrency management should be handled by events, not by<br>
&gt;&gt; multiple threads.[....]<br>
</blockquote><div><br>libevent can be used for event-based servers.<br>
<a href="http://www.monkey.org/~provos/libevent/">http://www.monkey.org/~provos/libevent/</a><br>
<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
&gt; Interesting. &nbsp;Makes sense, but a lot of boilerplate code for daemons has<br>
&gt; always used the fork approach. &nbsp;Of course, things were &quot;smaller&quot; back<br>
&gt; when the approach was dominant. &nbsp;The forking approach is easy to program<br>
&gt; and reminiscent of pipe code and so on.</blockquote><div><br>This site describe several approaches to solve this problem:<br>
<a href="http://www.kegel.com/c10k.html">http://www.kegel.com/c10k.html</a><br>&nbsp;<br>Look for <a name="x15">Chromium&#39;s</a> X15. It can handle thousands of simultaneous conections and can saturate gigabit networks even with lots of slow clients.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Sure, but it is way inefficient. Every single process you fork means<br>
another data segment, another stack segment, which means lots of<br>
memory. Every process you fork also means that concurrency is achieved<br>
only by context switching, which means loads of expense on changing<br>
MMU state and more. Even thread switching is orders of magnitude worse<br>
than a procedure call. Invoking an event is essentially just a<br>
procedure call, so that wins big time.</blockquote><div><br>As fas I know, process creation can take up to 1,000,000 cycles.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Event driven systems can also avoid locking if you keep global data<br>
structures to a minimum, in a way you really can&#39;t manage well with<br>
threaded systems. That makes it easier to write correct code.<br>
<br>
The price you pay is that you have to think in terms of events, and<br>
few programmers have been trained that way.<br>
<br>
Perry<br>
<font color="#888888">--<br>
Perry E. Metzger &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:perry@piermont.com">perry@piermont.com</a><br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</font></blockquote></div><br>
<br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.