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

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-12 18:57:47

On Sat, 10 Jan 2004, Matthew Hurd wrote:
>
> > On Behalf Of Sean Kelly
>
> > 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.
>
> Closing the socket would not be acceptable, nor would be relying on sending
> data, for many applications, so from what you say timeout is the way forward
> for a select() kind of thing.

Alexander Terekhov did note a (platform-specific) method for signalling
select().  I haven't used this myself but I imagine it could be a viable
alternative.

> I can see how cancelling threads can help model things if it can be done in
> an appropriate manner, but I think it is much healthier to design thread
> shutdown from the thread's point of view, which requires them being able to
> react to a shutdown event, that is, not block indefinitely and loop checking
> the shutdown flag, or some such.  Which, I think, is in line with what you
> are saying...

Pretty much.  I don't think it's safe to assume that (a) the thread is
still running or (b) is in a state where it can respond to a shutdown
signal in a timely manner.  I would typically check if a thread is
running, signal a shutdown, and either give up on it or terminate it if it
hadn't exited after a fixed interval.  So worst-case shutdown of a lot of
threads might take a while, but this would only be in the evet of many
running threads who did not respond to the shutdown signal.

Alexander Terekhov did mention an upcoming way to check if a pthread
(really, whatever that thread handle currently references) is still
running.  This is great news, I definately plan to use that in my thread
object.

> Presently, we have mutexes and conditions in boost.  We want to add other
> things that we can block on and wait for.  In particular, asynch i/o and
> cancellable active objects have been mentioned, but many others spring to
> mind.  This is a further abstraction from mutex but similar in most
> interface requirements.  What about the name blocking_type, wait_type?  Is
> there a common name?  Windows just calls them kernel objects.

I don't think so.  Find a nomenclature that works for you.  I have a
generic "event" object, a "locker" base type that I inherit mutex and
critical section types from, etc.

Sean