From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 12 20:47:05 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94A4516A404 for ; Thu, 12 Apr 2007 20:47:05 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 39DC713C45A for ; Thu, 12 Apr 2007 20:47:04 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 2775 invoked by uid 1001); 12 Apr 2007 20:46:48 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Thu, 12 Apr 2007 16:46:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17950.39608.313810.327993@bhuda.mired.org> Date: Thu, 12 Apr 2007 16:46:48 -0400 To: Daniel Taylor In-Reply-To: <20070412203354.27926.qmail@web27714.mail.ukl.yahoo.com> References: <17950.36826.926845.213901@bhuda.mired.org> <20070412203354.27926.qmail@web27714.mail.ukl.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: tcp connection splitter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 20:47:05 -0000 In <20070412203354.27926.qmail@web27714.mail.ukl.yahoo.com>, Daniel Taylor typed: > queue algorithm that I can use to avoid it. My > problem with async I/O is that it's unnecessarily > complex and inherently unportable. I don't know about "unnecessarily" complex. It's certainly less complex than most of the alternatives. As for unportable - no more so than anything else. Yeah, if you want it to run on a cell phone or your watch, you may have problems (then again, you may not - see below). On the other hand, the only thing about doing async I/O that's creates any portability issues is detecting events. That's got the usual portability/speed tradeoff. If portability is really important, use select() (the major problem here is that certain desktop platforms don't support select() on a disk file, but that doesn't matter in your case). Need more perforamce but still want some portability? Use libevent, which can live on top of a number of different mechanisms. Want to go as fast as you can and don't care about portability? Use kqueue (on FreeBSD, anyway). For most such things, you're spending most of your time waiting on network I/O, so using a VM of some sort (Java, Perl, Python, etc.) is perfectly acceptable. In that case, the portability issues are liable to have been taken care of by the folks porting it to your platform, so you can run it on any platform they support - like Python on the Symbian phones, or Java on most JME phones. > (I was thinking along the lines of "maintain two > queues, one for reading, one for writing, and switch > them in one atomic op when the clients drain the > reader queue", only less crude.) If you find it, I could use it as well. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.