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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk