tcp connection splitter
mwm-keyword-freebsdhackers2.e313df at mired.org
Thu Apr 12 20:47:05 UTC 2007
In <20070412203354.27926.qmail at web27714.mail.ukl.yahoo.com>, Daniel Taylor <daniel_h_taylor at yahoo.co.uk> 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.
Mike Meyer <mwm at mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
More information about the freebsd-hackers