RE: [boost] Re: Re: Boost.Thread : IO multiplexing
On Behalf Of Sean Kelly
What remains an issue in my mind is how far to take this. Socket and file classes for each platform at least... what else?
Waitable timers would be the other "main" one I'd guess. Some process abstractions might be straight forward for "kill" signals and the windows equivalent. I would still like to see mutexes, timers, socket i/o and file i/o all with similar acquisition concepts so there is a hope of marrying them down the track if it is not done up front. The other thing I'd like to see is a substitutable framework, like the synch stuff I posted a while ago, where you can develop to a particular policy concept, for example a shareable mutex, then substitute a single threaded or null mutex or anything else in. ACE has had something similar for many years and it is straight forward. The current interface does not support such use AFAICT, hence the synch wrapper I use. I'd be happy to document and clean this up if there is interest. 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
What remains an issue in my mind is how far to take this. Socket and file classes for each platform at least... what else?
Waitable timers would be the other "main" one I'd guess.
Unfortunately, I do not believe that it is possible to wait on both a timer and a file descriptor on POSIX platforms, so this is the same situation as mutexes (see below).
Some process abstractions might be straight forward for "kill" signals and the windows equivalent.
Signal handling abstraction is probably best done by a separate library. Signals are useful for dealing with asynchronous i/o on POSIX platforms, but I would recommend that non-blocking, but not asynchronous I/O be used by the library on those platforms.
I would still like to see mutexes, timers, socket i/o and file i/o all with similar acquisition concepts so there is a hope of marrying them down the track if it is not done up front.
I believe it has been concluded that there is pretty much no way at all of efficiently waiting on both a mutex and a file descriptor on most POSIX platforms, including Linux and BSD. Furthermore, it is also inefficient on Windows, since it requires use of WaitForMultipleObjects, which doesn't scale well. I would not recommend that an i/o multiplexing attempt to handle mutexes and timers.
[snip]
-- Jeremy Maitin-Shepard
On Wed, 28 Jan 2004 23:04:57 -0500, Hurd, Matthew wrote
On Behalf Of Sean Kelly
What remains an issue in my mind is how far to take this. Socket and file classes for each platform at least... what else?
Sorry to jump into the conversation mid-stream... I'm hoping you'll have looked at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket which documents prior work in this on sockets and multiplexing by a variety of boosters. The work seems to have stalled out, but there is an implementation in the sandbox along with requirements, etc.
Waitable timers would be the other "main" one I'd guess.
Yep, that's a big one.
Some process abstractions might be straight forward for "kill" signals and the windows equivalent.
I would still like to see mutexes, timers, socket i/o and file i/o all with similar acquisition concepts so there is a hope of marrying them down the track if it is not done up front.
In ACE this the the Event_Handler class. http://www.dre.vanderbilt.edu/Doxygen/Stable/html/ace/a01234.html However, in my mind this class doesn't go far enough because it tightly couples timer callback interfaces (handle_timeout) with file i/o (handle_input) and signals (handle_signal). Thus a pure timeout handler, for example, brings a lot of baggage as well as virtual functions. In the brave new world of policy design it seems like we should have an EventHandler class that can take a list of reactive handler classes/policies so that the designer can mix and match to generate a handler class which can respond to several of these different input types. Of course the reactor type needs to be a policy as well because despite the limits of WFMO it might be the prefered choice on Windows while a Select reactor might be used on Unix -- and the code would still be portable for a large percentage of applications.
The other thing I'd like to see is a substitutable framework, like the synch stuff I posted a while ago, where you can develop to a particular policy concept, for example a shareable mutex, then substitute a single threaded or null mutex or anything else in. ACE has had something similar for many years and it is straight forward. The current
Yes, I agree with this is important. It is a case where ACE had policy-based design b/f it was 'popular'.
interface does not support such use AFAICT, hence the synch wrapper I use. I'd be happy to document and clean this up if there is interest.
Absolutely. And more globally I'd like to see a small working group get organized and actually bring these libraries to the point where they can be included in boost... Jeff
On Thu, 29 Jan 2004, Jeff Garland wrote:
I'm hoping you'll have looked at
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
which documents prior work in this on sockets and multiplexing by a variety of boosters. The work seems to have stalled out, but there is an implementation in the sandbox along with requirements, etc.
Thanks. I was unaware that this had been done, and the design seems pretty nice. One thing I'd like to clarify though, it seems there are two models. The basic examples use a stream metaphor to read/write data and seem as if read operations will block until the data is available. The other uses an observer pattern to receive events as they occur, which would be used with multiplexing server implementations. Is this correct? Sean
On Thu, 29 Jan 2004 14:01:52 -0800 (PST), Sean Kelly wrote
Thanks. I was unaware that this had been done, and the design seems pretty nice. One thing I'd like to clarify though, it seems there are two models. The basic examples use a stream metaphor to read/write data and seem as if read operations will block until the data is available. The other uses an observer pattern to receive events as they occur, which would be used with multiplexing server implementations. Is this correct?
Yes, that is correct if my memory serves me. However, I think in the implementation (which is in the sandbox) only the blocking version is implemented -- but I honestly haven't looked at it for probably 6 months. Jeff
participants (4)
-
Hurd, Matthew -
Jeff Garland -
Jeremy Maitin-Shepard -
Sean Kelly