RE: [boost] Re: Re: Boost.Thread : IO multiplexing
On Behalf Of Sean Kelly Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
IOCP works for both file and socket operations. Perhaps not a poll method but I'm not much interested in the low-end solutions anyway.
Small point. Please don't knock the pollster ;-) Polling trades CPU for latency gain. Polling is a high end solution for low latency requirements, which covers a lot of my issues (not the psychological ones though ;-)). Not so good for high throughput systems, but it can be. A combined approach, poll for a while you can then wait for an interrupt ( a bit like spin-locks ), can be especially beneficial for supercomputer oriented frameworks as plenty of research shows. A polling, single threaded architecture is often best for the style of performance oriented apps I develop. I have also seen some neat SAN software developed with polling that wouldn't have otherwise worked at all well. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"Hurd, Matthew" <hurdm@sig.com> writes:
On Behalf Of Sean Kelly Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
IOCP works for both file and socket operations. Perhaps not a poll method but I'm not much interested in the low-end solutions anyway.
Small point. Please don't knock the pollster ;-)
Polling trades CPU for latency gain. Polling is a high end solution for low latency requirements, which covers a lot of my issues (not the psychological ones though ;-)). Not so good for high throughput systems, but it can be. A combined approach, poll for a while you can then wait for an interrupt ( a bit like spin-locks ), can be especially beneficial for supercomputer oriented frameworks as plenty of research shows.
While poll(2), like select(2), is indeed rather inefficient on many platforms, other polling mechanisms, such as epoll, kqueue, and /dev/poll can scale quite well. On Windows platforms, I think it is clear that asynchronous I/O is almost always more efficient than polling, and I believe Sean Kelly, in recommending against polling, was referring exclusively to Windows platforms.
[snip]
-- Jeremy Maitin-Shepard
Hi, I have been following this thread with interest, and at this point I think it might be worth jumping in and mentioning an experimental C++ networking library I have been developing over the past six months or so: http://www.tenermerx.com/programming/cpp/asio/asio-0.1.5.tar.gz I chose to "unify" the different types of resources behind an asynchronous interface (similar in some respects to the boost net prototypes) in addition to supporting blocking calls. Currently the library supports sockets and timers, although I do plan to extend this. It does not present a non-blocking interface through the external API, but it does use select internally for its non-Win32 implementation. Since my hypothesis is that I should be able to write portable, decently performing, network apps using only asynchronous calls, I have tried to make it straightforward to integrate non-asynchronous APIs into the event dispatching framework. I also attempt to obviate the need for directly using mutexes and condition variables in "application code" through a few simple rules for delivering the events. However I haven't road tested these concepts in a large real-world app yet, so I can't say for sure ;) The core IO demultiplexing concepts came from the work of my former colleague Alex Libman in developing a "portable Proactor framework" for ACE (see http://www.terabit.com.au). This is a Proactor that can use select if no more appropriate OS mechanism is available. I mention this because Alex has had great success integrating support for a range of i/o mechanisms, such as kqueue, Win32 IOCP, AIO on Sun, /dev/poll and RT signals, to try and use the best one for each platform but present a consistent interface. I am using the library as an experimental platform for a whole bunch of other ideas, but I'll save them for anyone who's actually interested :) Cheers, Chris
participants (3)
-
Christopher Kohlhoff -
Hurd, Matthew -
Jeremy Maitin-Shepard