RE: Re[2]: [boost] Re: Boost.Thread: Wrapping Native WindowsEventVariablespossible?

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-08 22:57:56

On Thu, 8 Jan 2004, Hurd, Matthew wrote:
>
> The first idiom, of timed waiting and predicate checking, or something
> else would still be required for active object cancellation where the
> object is waiting on OS blocking things and you don't have a WFMO
> equivalent though.
>
> Without a WFMO equivalent a boost implementation would have to:
>
>   1. block on each of them with a separate thread
>   2. be able to stop the other waiting threads from waiting when one
> fires.
>
> It is not pretty.
>
> So I think boost needs a portable interface to a WFMO equivalent.  Is
> there an equivalent for POXIS, linux, solaris that is appropriate.
> Perhaps a WFMO abstraction would be appropriate for asynch I/O?

Depends on the type of IO.  The only way to interrupt select() is to send
data to a listening socket it's polling or close a socket it's polling.
IIRC there is a way to signal IOCP to wake up though, I do it in the
destructor of some of my comm. objects.

> A general implementation without direct OS support could have built with
> timed blocking (very ugly) or cancelling threads (still very ugly just
> less so from a performance viewpoint but perhaps more so from a
> robustness viewpoint).  I don't think either of these are appropriate
> options.

One slightly irritating feature of pthreads is that there's no supplied
way to determine whether a thread has exited.  A suggested method to
shutdown a thread might be to signal it and then join it, but IMO you
would still want to have the wait for completion to time out as  I can
think of a few instances where waiting indefinately for completion
could cause problems.

> Solving the cancellation with allow the messy solution of having various
> threads blocked waiting for individual objects to work, but it is still
> ugly and wasteful and should cause you to run a few miles in the
> opposite direction.

If the thread loop is written correctly a timed wait isn't much of a
performance hit, and in some cases the only workarounds are complex and
error-prone.

Sean