🚀 go-pugleaf

>I see your point. That wasn't a problem in Win16 because there was no
>such thing as multi-threading. Is it possible to build a Java app that
>does not multi-thread? I mean, if I avoid starting new threads myself,
>and post events to the queue, will the OS still (potentially) break away
>from my code block and deliver the event to its target before my code
>block is finished?


If you have written all the code as single threaded, the posted messages
will stay in the queue until the current message completes...maybe.

I have a real life example of how this can fail, even under g'ol Win16 apps.
I maintain a Win16 application that communicates with an instrument over the
serial port.  The app uses a good (an pricey) library that manages the
serial port.  That library was written by some nice programmers.  Serial
port instruments are slow compared to a 200 MHz cpu; you often wait several
hundred milliseconds for a response.  Under Win16, you would sacrifice much
liveness if your app was dead most of the time waiting for responses.  The
comm library _solved_ this by setting up a secondary message dispatch loop
inside the wait for response.  You've seen these little
Peek/Translate/Dispatch loops wonders right, everyone uses them in
"background tasks".  Well, this is a nightmare.  User clicks Go.  Code
executes down to the wait for response from that slow instrument point.
User thinks, "hey nothings happening and clicks Go again and a message gets
posted into queue.  That secondary dispatch loop says "hey I'm not doing
anything but waiting for this slow serial port, I'll dispatch a few messages
and add some liveness to this application"  Code executes down to same
point--did we write re-entrant code? No.  It was a debugging nightmare,
because it wasn't documented except by reading all through the source code.
It was just done to improve my application for me :)

So, if you just post a message into the queue, it will stick unless
somewhere else there is peeking into the queue.  If you write everything you
rself, no problem.

From a design perspective, I think posting messages is not solid (even
though I have done the same in the past).  Imagine a type of macro player
and a spastic user clicking away.  Can you guarantee that the
programmatically posted messages are mixed with user messages in a specific
order? No.  Is it true that your program is completely insensitive to the
order of messages...maybe.

Think threads

bye,
  Jim