Boost logo

Boost :

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-29 04:03:27


"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).

> 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

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