From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 12 20:33:56 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 4436516A403 for ; Thu, 12 Apr 2007 20:33:56 +0000 (UTC) (envelope-from daniel_h_taylor@yahoo.co.uk) Received: from web27714.mail.ukl.yahoo.com (web27714.mail.ukl.yahoo.com [217.146.177.248]) by mx1.freebsd.org (Postfix) with SMTP id BA2EA13C45E for ; Thu, 12 Apr 2007 20:33:55 +0000 (UTC) (envelope-from daniel_h_taylor@yahoo.co.uk) Received: (qmail 27928 invoked by uid 60001); 12 Apr 2007 20:33:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aCQFupl5XOANuesoX9fRAAQIuzfYCq7/QgcKc+/s1T9sPu9xf7f+A6JMN4sRtE0jJTZU9niO6uHN14RdTMy0NlMupaXDsdfWyGHsrmKsElN5XDKgSL0Mqdz3+UutOXOus9xrVKBbdWw2nZMHw/w5wJRD0QJblV3IU9pjjdGxQ+k= ; Message-ID: <20070412203354.27926.qmail@web27714.mail.ukl.yahoo.com> X-YMail-OSG: KR9cheIVM1n3EbsAH4Av_kod0M1t1V04pEx8knM5JtX33ZaF.pYrwrXjcu28KMopYcBlAyUcqnHX3QIq53ncgMhFkETO9a7H6KzgkK4knwLftXMsPjEsc59dlV8- Received: from [38.117.185.138] by web27714.mail.ukl.yahoo.com via HTTP; Thu, 12 Apr 2007 21:33:54 BST Date: Thu, 12 Apr 2007 21:33:54 +0100 (BST) From: Daniel Taylor To: freebsd-hackers@freebsd.org In-Reply-To: <17950.36826.926845.213901@bhuda.mired.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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:33:56 -0000 > > Each > > enqueue bumps the refcount, each dequeue decreases > it; > > when the refcount drops to 0, the packet is > free()'d > > (by whomever happened to dequeue it last). > > These operations have to be locked, so you have to > acquire and release > 1 mutex lock N+1 times. Well, I was using atomic counters (based on cmpxchgl), which are much faster than pthread mutexes, but still. > The FSM model already suggested works well, though I > tend to call it > the async I/O model, because all your I/O is done > async. You track the > state of each socket, and events on the socket > trigger state > transitions for that socket. The programming for a > single execution > path is a bit more complicated, because the state > has to be tracked > explicitly instead of being implicit in the PC, but > *all* the > concurrency issues go away, so overall it's a win. I'm beginning to think that async I/O within a single thread is the only way to go. Unless there's some fancy lockless single writer multiple reader 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 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.) Dan ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com