RE: [boost] Re: Re: Boost.Thread : IO multiplexing
-----Original Message----- From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] Sent: Thursday, 29 January 2004 7:03 PM To: boost@lists.boost.org Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
"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).
It is easy enough to do this - for example see ACE's Reactor Notify for details. If you care about other threads you need the notify interface to force a wake-up when a new timeout needs to be calculated, otherwise just calculating the timeout parameter from the head of the timer queue before blocking is enough.
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.
I don't see why the library shouldn't be generic enough to allow a unification on a platform that supports it. It may not be all that mythical - I'm sure there was some discussion and patches on lkml some time back suggesting that it is possible to extend epoll to work with futexes. On the opposite side of the coin, Linux 2.6 has extended aio in the kernel that should make aio a pretty reasonable option for that platform and at least tries to address most of the negatives mentioned re using aio on Posix platforms. Haven't tried to actually use it yet though! Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################
"Darryl Green" <Darryl.Green@unitab.com.au> writes:
-----Original Message----- From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] Sent: Thursday, 29 January 2004 7:03 PM To: boost@lists.boost.org Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
"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).
It is easy enough to do this - for example see ACE's Reactor Notify for details. If you care about other threads you need the notify interface to force a wake-up when a new timeout needs to be calculated, otherwise just calculating the timeout parameter from the head of the timer queue before blocking is enough.
Okay, I suppose this can be done.
[snip]
I don't see why the library shouldn't be generic enough to allow a unification on a platform that supports it.
I suppose it is possible, but is there any platform other than Windows that supports it? Also, it seems that the interface to support waiting on a mutex would be too loo-level to then allow use of either asynchronous I/O or synchronous I/O, depending on the platform.
[snip]
On the opposite side of the coin, Linux 2.6 has extended aio in the kernel that should make aio a pretty reasonable option for that platform and at least tries to address most of the negatives mentioned re using aio on Posix platforms.
I may be mistaken, but it seems that the new asynchronous I/O completion system at least currently cannot be used with sockets. -- Jeremy Maitin-Shepard
Jeremy Maitin-Shepard wrote:
"Darryl Green" <Darryl.Green@unitab.com.au> writes:
I don't see why the library shouldn't be generic enough to allow a unification on a platform that supports it.
I suppose it is possible, but is there any platform other than Windows that supports it? Also, it seems that the interface to support waiting on a mutex would be too loo-level to then allow use of either asynchronous I/O or synchronous I/O, depending on the platform.
I'm currently leaning towards picking up work on the existing Boost.Socket implementation and adding generic waits at a higher level or perhaps in another package? There's no reason a condvar can't be used for this type of thing. No need to rely on nonportable library calls. Sean
participants (4)
-
Darryl Green -
Jeremy Maitin-Shepard -
Sean Kelly