Re: Message queue processing in a thread

In <V72dnfe2gJPk6KfbnZ2dnUVZ_hKdnZ2d@xxxxxxxxxxxx>, on 05/03/2007
at 04:51 PM, Jim Moe <jmm-list.AXSPAMGN@xxxxxxxxxxxxxx> said:

Hi,

Another question that arises: Why? Why recommend processing the
messages in a separate thread?

Because it leaves the main thread free to act as a traffic cop.
Generally, it's easier to to complex recovery actions from the main
thread, but OS/2 is designed this way. It's a good idea, but few apps
bother to do this. Most create the main message queue and windows on the
main thread.

The queue can still get jammed.

This will not happen with good app design regardless of which thread does
the message processing.

One possibility is that the input queue is supposed to
be drained immediately and the messages sent to the threaded queue.

This is true for all queues. See below.

This would
entail creating an internal queue, initializing windows in main() as
before, and using the typical dispatch loop to dequeue and post the
messages to the internal queue. Is this sensible? Worth the effort?

No.

A typical clean design will arrange for the message handlers to hand off
long running functions to one or more separate threads. Often one or more
of these separate threads will implement object windows. Object windows
are handy because they are easy to communicate with using the standard PM
message passing services.

This kind of design requires some planning. The UI has to let the user
know how things are going on these otherwise invisible threads.

Basically it's lazy programming that causes an app to hog the desktop.


Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@xxxxxxxxxxxxxxxxxxx> MR2/ICE 3.00 beta 04 #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

.

Relevant Pages

  • Re: How hard is socket programming?
    ... day there was still 21,000 page faults. ... It won't scale this way at all, I tested it and it fails ... It won't scale because you not using common design ... of items already in the queue when it was added. ...
    (microsoft.public.vc.mfc)
  • Re: Can extra processing threads help in this case?
    ... when queue length exceeds some limit. ... that grow (if this is actually true of linux named pipes). ... flawed design of yours. ... possible reasoning, and you simply ignore what I say. ...
    (microsoft.public.vc.mfc)
  • Re: parallel programming
    ... end of the queue must be serviced by some auton, ... The point is that any design would be exposed. ... Locking is just a way to synchronize. ...
    (comp.programming)
  • Re: Can extra processing threads help in this case?
    ... of whichever portion of the queue applies to this priority. ... involves no linear searches and no separate heads. ... Since the design will be perfect, and the first implementation will work absolutely ... computers such as Pentium I or Pentium 2 or Pentium Pro as donations? ...
    (microsoft.public.vc.mfc)
  • Re: Strange Behavior
    ... That sounds like it would work if that was how the algorithm was designed. ... Could that kind of design still cause what you are describing? ... I have two timers polling - and this could be the real ... > second thread poll the state of the queue; it should block on a semaphore if the queue is ...
    (microsoft.public.vc.mfc)