Date: Thu, 12 Apr 2007 21:33:54 +0100 (BST) From: Daniel Taylor <daniel_h_taylor@yahoo.co.uk> To: freebsd-hackers@freebsd.org Subject: Re: tcp connection splitter Message-ID: <20070412203354.27926.qmail@web27714.mail.ukl.yahoo.com> In-Reply-To: <17950.36826.926845.213901@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070412203354.27926.qmail>