Thread Finishes before firing all UserInterfaceUpdate events

General
1

I am not really sure, but I might have a faint memory this topic had been, ehm, topic before.
I noticed it when I moved a thread-based class from a Mac Desktop app where it was working perfectly to a Linux console app. It was working too, but the result file was never written, and as I found out the last two processing steps were missing too. All that processing, and the success, are reported internally via UserInterfaceUpdate event scheme. The last few went missing.

The error was easy to fix by just having the thread idle a short time at the end.
But for me, this feels like a bug. A thread should not consider itself finished before all internal events have been fired. Or am I wrong?

2 Likes
2

Been bitten by this bug in the beginning whe the new thread UserInterfaceUpate event was added. Looks like it’s still an issue. It’s kinda serious bug since it just skips handling your data entirely.

2 Likes
3

I’ve never used the new event but the scenario you describe would not be unexpected to me. I wouldn’t be surprised if this was just using a timer to call the main thread which gets stopped when the thread ends.

My suggestions…

  1. The event is for updating the UI so don’t use it for anything more important.

  2. At the end of the thread Run event, use a timer / call later to invoke code on the main thread to show the final UI state.

4

i can’t find the case anymore but the thread UserInterfaceUpdate event did not raise always, it would miss data sometimes (first ever call to AddUserInterfaceUpdate and last calls where mostly missing data).

5

I’m confused. Why would you use UserInterfaceUpdate in a console app?

6

Because this class is designed as shared code that can be used inside a desktop app too. Where I want to have UI updates and trigger the save event after finish. So easiest thing was to use the Update event.

7

They end if they reach the end of the run() event.

Maybe you could add a loop at the end waiting for a thread state change to ThreadStates.NotRunning to exit the loop doing some micro-sleeps while “running”.

In your last AddUserInterfaceUpdate() send something as (“end”, 0) and in the UserInterfaceUpdate event fire a thread.stop when receiving it to release the thread from that waiting loop and gracefully end it.

8

Try putting this at the end of your thread’s code:

App.YieldToNextThread

That may cause the main thread to “catch up” and process all your queued up updates.

9

Any thread I have that writes to the UI, pauses for one second as it terminates. But @Rick_Araujo 's suggestion of a handshake at the end is much more robust.

10

The idea is a kind of more complex and verbose async/await.

11

Yes, well my stuff is pretty much set up to do that. The thread can make a special UI request and then suspend itself. My method that handles all the UI requests in sequence will simply resume the thread.