Date: Thu, 12 Apr 2007 16:46:48 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: Daniel Taylor <daniel_h_taylor@yahoo.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: tcp connection splitter Message-ID: <17950.39608.313810.327993@bhuda.mired.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In <20070412203354.27926.qmail@web27714.mail.ukl.yahoo.com>, Daniel Taylor <daniel_h_taylor@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 -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17950.39608.313810.327993>