2013 R3 has a ton of IDE and framework fixes that are very much appreciated, but I’ve spent several days intensively using it, and I can now say categorically that it’s simply not usable in a production environment, due to these two bugs:
On Cocoa, I can use 2013 R3 for limited testing, since the app will basically function normally (with the exception of horrible performance as it’s idling at 80%+ CPU use).
On Win32, I really can’t use 2013 R3 at all: the app just locks up randomly with “Not Responding” messages - this seems to be worse on a 1CPU core system but I’m seeing similar issues in further testing on multi-core PCs as well.
From my perspective, these issues are absolute showstopper bugs : there simply no way I can sell an app that hangs, or idles using 100% CPU.
But of course I have only my perspective - it would be interesting to hear from other folks who use Threads in their apps - are you also seeing these issues? Have you found any workarounds?
You can also vote with your points by voting for 29327 and 29633.
I can probably limp along for a while by doing this:
I’m not seeing the cpu issue for the Cocoa calculator that I wrote that does all of its processing in a thread. It spikes during calculations (as it should) and idles to zero percent afterwards. I check the thread status using a timer.
is your thread running all the time, or only during calculations? The issue I’m seeing is that a thread that is Sleep()ing causes CPU usage to spike. I suspect if you start a thread and then end it, you won’t see the issue.
have you benchmarked your app in R3 vs R2 ? I’m curious if the thread CPU usage I’m seeing is always present vs. something that goes away when the thread is not sleeping? (For example, it could be that your app runs much more slowly in R3 than R2 but you haven’t noticed it)
cThread.Run (a Thread subclass)
while true
if (there is stuff to do)
do a chunk
sleep(1) // yield some time, then come back and do more work
else
// nothing is happening
sleep(10) // no work to be done, sleep a little longer
end if
wend
Right now, my design is that these classes are Thread Subclasses - so there’s no easy way to just kill them, as they need to be persistent.
I’m sure I could inside-out the design, and have a Class which is not a Thread subclass, but has a property which is a thread subclass, which is created/killed as needed, but that would be a non-trivial redesign.
I have a feeling this might help on Cocoa, but not on Win32, but I don’t know at this time.
FYI Almost every app I made uses threads and there is no excessive CPU use when idling.
Those apps are always tested on 10.6 up to 10.9 before I release them.
is your thread running all the time, or only during calculations? The issue I’m seeing is that a thread that is Sleep()ing causes CPU usage to spike. I suspect if you start a thread and then end it, you won’t see the issue.
Only during calculations. I check for thread completion with a timer.
have you benchmarked your app in R3 vs R2 ? I’m curious if the thread CPU usage I’m seeing is always present vs. something that goes away when the thread is not sleeping? (For example, it could be that your app runs much more slowly in R3 than R2 but you haven’t noticed it)[/quote]
When my thread is active it is doing serious number crunching so it will drive the cpu to 100% consistently but is expected. I haven’t benchmarked this threaded app lately but I expect that for me there is no difference between R2 and R3. I have benchmarked another very cpu intensive app that does quadratic sieve factoring of large integers with runs of several hours and R3 performs as well as R2 for it. However it is not threaded.
In any event, I am not using the sleep function in my calculator. That may be a player in this issue.
+1
I’ve been using sleep to encourage my progress window to show up in database operations. When I tested my app on 2013r3 I only saw 20% activity or so and not 98%.
Threads have to yield time to be useful (since this is cooperative multi-threading). Currently in Xojo, threads yield in 4 ways:
at a loop boundary (unless #pragma DisableBackgroundThreads is in effect)
by calling Thread.Yield
by calling Thread.Sleep
a few isolated framework calls that yield internally.
Using “sleep” is no different than calling “yield”, except with Sleep you can specify a desired amount of time to yield.
So, if you don’t use “Sleep” then you are not able to do very good fine-tuning of thread behavior, which in a real-time multithreaded app, can be quite important.
For those of you saying that you see no problems with Threads in Cocoa, it’d be great if you could run the sample project I uploaded in https://xojo.com/issue/29633 and report back what you see. I see about 1% normally and 80% CPU when the thread is sleeping.
2013R3 introduced changes affecting this process (at least for Macs).
FIX 28228 MacCocoa: Threads now yield reliably when there are no timers, user input events, or sockets.
FIX 28333 MacCocoa: Threads now yield reliably when there are no timers, user input events, or sockets.
[quote=35692:@Rick A.]2013R3 introduced changes affecting this process (at least for Macs).
FIX 28228 MacCocoa: Threads now yield reliably when there are no timers, user input events, or sockets.
FIX 28333 MacCocoa: Threads now yield reliably when there are no timers, user input events, or sockets.[/quote]
Yes - I can’t view either of those cases (private? merged?) but this is clearly a smoking gun - thread behavior was changed, and most likely as a side effect of these changes, something broke.
