Boost logo

Boost :

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-29 10:37:23


"Darryl Green" <Darryl.Green_at_[hidden]> writes:

>> -----Original Message-----
>> From: Jeremy Maitin-Shepard [mailto:jbms_at_[hidden]]
>> Sent: Thursday, 29 January 2004 7:03 PM
>> To: boost_at_[hidden]
>> Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
>>
>>
>> "Hurd, Matthew" <hurdm_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk