Re: [boost] Re: Boost.Thread: Wrapping Native Windows Event Variables possible?

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

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

> 
> I can see that it would be common in certain types of programs, though 
> not in others (I, for instance, haven't needed to do this yet).
> 

Perhaps, your approach could be interesting to me. Perhaps  I am still doing
something that could be done simpler. I tell you about the problem where I
first found the need to wait for multiple IO operations.

I found myself writing a controller for a machine, that has a bidirectional
communication line via a serial (RS232) port. This controller however
also had to obey commands from a supervisory channel, that arrived 
asynchronously to the controller communication.
My solution there was to use the "select" system call (since this was on Linux)
to multiplex between the two channels.
The alternative would have been to wrap each communication endpoint (receive
and transmit separately) into a thread which`s sole purpose would have been to
wait. So even in this simple case I would have ended with 5 threads. 2 receive,
2 transmit, 1 controller. I think this is a lot of overhead.

> 
> > 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?
> 

To be honest. I do not yet have a convincing idea, just some thoughts,....

What I think is fundamental is that the cond.wait() is not sensible to operating
system events at all. 

Perhaps its semantic could be extended to deliver
spurious wake-ups on (for this pupose registered) file/port IO events?
Or the file descriptors to wait on, could be added to the parameter list
of wait() ? (Don't like this, because file descriptors aren't very portable, aren't they?)
This would be similar to the Win32 API "MsgWaitForMultipleEvents" which wakes
up the thread when any windows message is arriving at the threads queue in
addition to the synchronization object wait is blocked on.

But this also would require some similarities in low-level file IO. AFAICS the
similarities do exist in "non-blocking" and "blocking" IO. Altough on posix
one would need to use the SIGIO asnchronous signal and translate this
to notify_one / notify_all calls. Select I think is not workable, because
there is no similar counterpart in the Win32 API. (Isn't it?)

Hmm, I will think a little more about this. Perhaps I should also cross-post
this question to a multithreading group, as some of the problems are not
boost only I think.

regards,
Roland