Strange thread problem

I’ve got a problem with a thread that I don’t understand.

The window tells the model to do start doing stuff.
The model starts a thread to do the stuff.
The thread does the stuff.
At the end of doing the stuff the thread signals the model that it is finished.
The model get’s a notification and does some cleanup tasks.

Unfortunately, I got some reports from customers that one of the cleanup tasks is started and then the thread goes on doing stuff. Since both doing stuff and the cleanup task involve the same database this results in a crash. I have never seen this problem myself and on good days I do debugging dozens of times.

Here is the last section of the session log from the customer:

2017-02-04, 11:51:41 emlxIterator.Constructor MailboxPath: iCloud:::some mailbox -> thread doing the stuff
2017-02-04, 11:51:41 emlxIterator.GetNumberOfObjects 1
2017-02-04, 11:51:41 ArchiveThread.Archive done -> thread is finished
2017-02-04, 11:51:41 MaxModel.DoDiagnose -> going back to model, starting clean up task
2017-02-04, 11:51:41 emlxIterator.Constructor MailboxPath: iCloud:::Familie -> thread is NOT finished
2017-02-04, 11:51:42 emlxIterator.GetNumberOfObjects 15 -> thread does stuff again, last information before crashing

Does anyone have an idea what could cause this? I’ve added some checks but these would only treat the symptom and not the root cause of the problem. There is only one thread at a time. Is there something fundamental that I have misunderstood when working with threads?

How does the thread signal the model when it’s done?

@Kem Tekinay: I’ve got a notification class which handles this. It’s a singleton.

But what’s the root mechanism, a Timer that raises and event or something like that?

What I’m thinking of is this:

  • Thread finishes and starts the process to signal the model. Thread dies.
  • Before model is actually signaled, thread is started again.
  • Model is signalled, but new thread is already running.

At any rate, it’s not clear if you have a semaphore controlling access to your database. If not, you should.

There is no semaphore controlling access. That’s a good idea but it would mean a large refactoring.

The root mechanism for the notification center is a simple observer pattern.

As far as I can see the thread isn’t started again. I should see this in both model and thread in the session logs. Also there is a progress window as a sheet so it’s impossible to start the thread without the previous one having finished.

  • Any chance that your users are running this on CPUs with a single Core? (either physical or virtual?)
  • Does the Xojo version matter?

I’m curious why you ask this, threads in Xojo don’t have the ability to use multiple cores.

I’ve seen “weird stuff” happen on single CPU cores with threads. <https://xojo.com/issue/30328> is an example describing high CPU usage. I’ve also seen event order change - my memory is fuzzy but I think that IPCSockets may behave strange as well on single core CPUs.

I doubt this is relevant but you never know.

Thank you!

@Michael Diehr: are there any current Macs with a single core remaining?

The Xojo version I have first seen this is 2015r4. Now the problem occurs for 2016r4.

I’ll check out the Feedback report. My app does do high CPU load.

[quote=314264:@Beatrix Willius]@Michael Diehr: are there any current Macs with a single core remaining?

The Xojo version I have first seen this is 2015r4. Now the problem occurs for 2016r4.

I’ll check out the Feedback report. My app does do high CPU load.[/quote]

Mostly I’ve run into this situation on Virtual Machines, as both VMWare Fusion and Parallels VMs default to 1 CPU.

The customer’s computer has 24 GB with 4 cores and my app was the only app running.

@Michael Diehr: Your feedback case was just closed today! I’m not sure if it’s related to my problem. I think for now I’ll add some logging for CPU load.