|
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