Re: [Boost-Users] Boost::Threads condition variable on Win32 and IO completion routines

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-21 16:24:01

Russell Hind said:
> The start of the do_wait() method of a boost::condition (in 1.29.0) for
> Win32 looks like this
>
> void condition::do_wait()
> {
>     int res = 0;
>     res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_queue),
> INFINITE); assert(res == WAIT_OBJECT_0);
>
> This waits indefinitely until m_queue is signalled.  Would it be safe to
> change this so the thread is alertable for IO completion routines?
> Something like
>
> int res = 0;
> while ((res = WaitForSingleObjectEx(reinterpret_cast<HANDLE>(m_queue),
> INFINITE, true)) == WAIT_IO_COMPLETION)
> {
> }
> assert (res == WAIT_OBJECT_0);
>
> We make fairly heavy use of Waitable Timers in our statemachines.  The
> completion routine for a timer is called back in the context of the
> thread that started it, when the thread is alertable.
> WaitForSingleObject doesn't allow the thread to be alertable.

I've not made use of alertable threads in Win32 to date.  Is it generally
a good idea to make all waits alertable, or should this be something that
the user can specify (which will be fun to make portable, but that's my
problem)?  Wouldn't you want all waits to be alertable, and not just this
specific one in boost::condition?

> We currently use this in our own thread (with Windows events) but are
> looking to update the message queue code and thread code to use boost.
> With out this change, it would currently break a lot of code if we were
> to use condition variables.

This doesn't work for Windows messages, does it?  For that you need
MsgWaitForObject(Ex), right?  That's one that's more difficult to address
for a number of reasons, but it should be addressed as well, and is on my
list of todos.

-- 
William E. Kempf