tcp connection splitter

Daniel Taylor daniel_h_taylor at yahoo.co.uk
Thu Apr 12 20:33:56 UTC 2007


> > 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


More information about the freebsd-hackers mailing list