There is something wrong with the prior thread https://forum.xojo.com/5068-2013-r3-is-not-usable-for-production-apps-for-me where most people can’t post responses. Let’s continue the discussion here please.
Recap: there are two issues that greatly affect me being able to make production-quality apps using 2013 R3:
Feedback Case #29327 Win32 Desktop Apps go unresponsive and have 100% CPU use with threads
Feedback Case #29633 Cocoa apps use nearly 100% CPU while idling.
29327 has been marked as “fixed” so, with luck, that won’t be an issue as soon as it’s released.
29633 however is not fixed, and seems to manifest itself as follows:
- In cocoa apps built using 2013 R3, any thread that is sleeping or suspended, will cause the main event loop to churn, using 80%+ of CPU while the app is idling.
The only workarounds suggested (but not extensively tested) are of the “Don’t do that” category: redesign your threaded apps so that they never Suspend or Sleep their threads. This is, naturally, a sub-optimal solution and I’d like to avoid that refactoring if possible.
Can anyone from Xojo Inc comment on the status of 29633 - can it be fixed? If so, when? The answer to that question will play a role in determining what steps I take next - do I rewrite my app or just wait patiently?
Thank you.
[Edit : Typos]
Michael you already know the answer.
Can I comment ? NO
Will I comment ? NO
WIll I give a date for it being fixed ? NO
FYI - Thom is NOT with Xojo any longer.
[quote=36325:@Maurizio Rossi]Hi Norman,
the scheduler or framework must raise an exception on illegal semaphore actions.
The application simply must not die losing control of itself.
I prefer a viable way to react to a fault instead of dying.
This is what I was reporting.
What is the intended use of things like exceptions and try/catch instructions?[/quote]
In the example with a secondary thread the ONLY thing that’s plausible is that, as the second thread is about to deadlock, we raise an exception. But that thread would HAVE to deal with it right then & there as the main thread could be deadlocked so App.UnhandledException could NOT run.
Suppose you had
app.open
start long running thread
signal
signal
then the long running thread finishes & exits its run event and all other threads are deadlocked so there is nothing to run when the thread exits. You’ll still get an assertion here as there is NO code that can run. And there’s no possibility to raise an exception since - all code is deadlocked.
There’s still a bug with the example that has NO secondary thread - it should have been asserting like the other example as it too should be in a state where the main thread deadlocked.
[quote=36421:@Norman Palardy]Michael you already know the answer.
Can I comment ? NO
Will I comment ? NO
WIll I give a date for it being fixed ? NO[/quote]
You won’t do that here - OK, but please don’t pretend like I’m asking for something unreasonable…
In a different thread discussing another bug, another Xojo employee did provide those answers, saying that the bug in question would not be fixed in time for 3.1, which is tremendously useful information and helps me plan my time.
Never said anything about reasonableness.
Can it be fixed is still under investigation.
You well know our position is not to promise dates - so please don’t ask for them either directly or by asking if something is going to be fixed for a specific version.
I completely understand the need to not promise fixes & dates, as it’s easy to get burned. But I also think the various situations are not entirely symmetrical - As an example, if one knows for sure that an issue is not going to be fixed in the next release, that’s a relatively safe statement to make.
In any event, I will take the information provided (or not) and use that to plan accordingly. Thank you.
Hi Norman,
I’m supposing to know the implementation limits of the framework.
Let’s talk about the deadlock case without any reference to bugs, feedback cases, feature requests and fixes dates.
Technically the deadlock can be avoided simply refusing to block the Signal() caller.
In this case the exception can be handled.
Like a Release() can generate “Illegal locking exception” something can be done for the Signal() method.
In a cooperative threading system all of this can be done more simply.
The scheduler has a more clearer view of threads states and a deadlock must be avoided.
The main thread has a very special role in this context and it can’t be locked.
I hope to not create confusion.
Best regards.
I’d like to thank Thom for all the time he has put in helping us. I wish him luck with whatever he will be doing next.
[quote=36573:@Maurizio Rossi]Hi Norman,
I’m supposing to know the implementation limits of the framework.
Let’s talk about the deadlock case without any reference to bugs, feedback cases, feature requests and fixes dates.
Technically the deadlock can be avoided simply refusing to block the Signal() caller.
In this case the exception can be handled.
Like a Release() can generate “Illegal locking exception” something can be done for the Signal() method.
In a cooperative threading system all of this can be done more simply.
The scheduler has a more clearer view of threads states and a deadlock must be avoided.
The main thread has a very special role in this context and it can’t be locked.
I hope to not create confusion.
Best regards.[/quote]
The only thing the scheduler can definitively know is when you are about to signal on the last thread that can be run & that would put everything into a deadlocked state. It can detect that doing this would deadlock the last running thread if it signals again.
What it cannot do is avoid ALL deadlock states no matter how they arise.
If the example you posted ran the secondary thread and that did some very long work then exited.
Something like
Main Thread
start worker thread
signal
signalAnd in the worker threads run event it did something like
Run
something that takes 10 seconds
exits run event
When the worker thread exits its run event there are NO threads that can be run and you cannot keep the worker thread alive, It’s existing its run event. At best the worker thread might get an exception - but if it has no way to unlock another thread (as your example had) the application will still exit with an illegal locking exception or something similar as there’s no other choice. Raising an exception on the main thread would be pointless since the main thread is deadlocked. That also means that App.UnhandledException is useless as too won’t run - it’s on the main thread.
There’s no other choice.