From: db3l@ans.net (David Bolen)
Subject: Re: Desynchronized Message Queues (was a thread about threads)
Date: Mon, 28 Sep 1992 16:36:40 GMT
	<1992Sep25.223019.18599@Informatik.TU-Muenchen.DE>
Organization: Advanced Network & Services, Inc. - Elmsford, NY

In article <1992Sep25.223019.18599@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes:

>In article <1992Sep25.175146.31043@ans.net> db3l@ans.net (David Bolen) writes:
>>Nope - won't help.  Anything using a message queue that gets user input has
>>to return to fetch the next event before more user input will be dispatched
>>to any other queues.  The only safe way to work this is to have the thread
>>that's doing the lengthy operations NOT have a PM message queue, and leave
>>the thread with the queue doing not much more than dispatching events.
>
>I don't think this is entirely true. A thread with lenghty operations
>may well have a message queue - it just should not create any windows
>for which the events would go into this queue, as you wrote in the first
>sentence.

Yes, that's entirely true - I should have been more explicit in my post
(I guess my excuse was I was trying to avoid getting even more complex).

Message queues themselves are a very useful means for handling
communication between threads, but you do have to be sure that they are
only being used by your application for inter-thread communications and not
for interaction with the user.

> (...)
>         AND this thread has it's own message queue, this is required
>in case a printer driver needs to open a dialog or message box,
>something that requires a thread doing this to have a message queue.

Of course, this isn't the best example, because this does represent
user interaction, and it's possible (although presumably unlikely) that
the printer driver, via user interaction, can hang the system because of
the single input queue.

>However, if not printing, the thread just sits in a DosReadQueue call
>waiting for new jobs and does NOT process a message loop. But this does
>not block the system, because there can not occur any event to be
>dispatched into the threads message queue because it does not have any
>windows which could receive input.

I agree.

>A thread with WINDOWS which can cause messages to be dispatched into
>it's queue (or any other source of messages, if there is any) should not
>do any job longer than a second (rule of thumb) while processing a
>message.

Yup.  The rub in this is that can you ever be sure that you're operation
will take less than a second (or whatever value you choose?)  You start to
get into the testability of an algorithm or program, and you've always got
the possibility of a bug (especially in any reasonably complex program)
that might suddenly show itself.  This is especially nasty during program
development, where a bug is even more likely.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/