Boost logo

Boost :

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-01-08 06:43:09

The original name of the Thread was: Boost.Thread: Wrapping Native Windows Event possible?

(Michael Glassford <glassfordm_at_[hidden]>) wrote:

> Roland wrote:
> > If this really is not possible, isn't there a need to provide such a feature?
> Probably, but in order to be portable it would need to be carefully
> designed. What would you envision it looking like?

I am not sure whether you are watching this thread any longer, but I
changed the topic to what I think is more appropriate.

After doing some search on the internet and studying the doc's I come
to the following:

Designing an interface for boost.thread will be hard, because there is
not yet a concept for (low level) IO at all. Yes, there are streams, and
a socket lib seems to be available sometimes. But these are all on
top of some system dependent IO, which is where multiplexing
needs to be implemented.

On the other hand I think asynchronous IO is of importance to
multithreading. Patterns like the Reactor Pattern are built on top
of this too. It is vital to be able to do multiplexing of IO in order
to avoid the 1 thread/client bottleneck.

While it is a challenge on its own to design a portable asynchronous
IO abstracction, every such design somehow would need to link
conditions with the native async IO mechanism of the relevant

So I come to the following idea:
Boost.Thread could supply intermediary (platform dependant)
functions to enable eventual IO lib designers a uniform interface.

i.e. on Windows supply a
cond.wait_wfmo(L& lock , DWORD nCount, CONST HANDLE* lpHandles)

while on Posix supply a
cond.wait_select(L& lock, int n, fd_set* readfds, fd_set* writefds, fd_set* exceptfds)

Unfortunately I do not see a way, how this could be done without
altering the code of condition.hpp so before giving it a try and start hacking
away I would like to hear some opinions. Perhaps there still is a way to emulate
this on top of boost.thread somehow?


Boost list run by bdawes at, gregod at, cpdaniel at, john at