Agree with the cursing…
cursing
Profiler & Threads: I submitted this in October 2009: <https://xojo.com/issue/10072> Is that what you are seeing?
Profiler & Crashes: there was a nasty bug where profiled code would crash (if it was sufficiently complex and involved threads). I’m pretty sure it was fixed, but I can’t find my original bug report (Feedback + Merged reports = ‘who moved my cheese’).
Threads + Semaphore - I’ll admit I don’t use semaphores at all, so this may be a dumb questions, but…
What should this code do?
Pushbutton1.action
self.mSem = new Semaphore
mSem.Signal // acquire lock
Thread1.run
end
Thread1.Run
self.mSem.signal // this should block the thread, right?
while true
dim x as integer = 42
wend
Testing this code, I find that Thread1 runs normally - it doesn’t stop at the Signal line. Am I misunderstanding how semaphores work?
Wow, the forum software is really misbehaving this morning.
Forum note: I just lost a post (clicked Post a Reply and nothing happened). Hitting the Back button (Safari 6) restored my post so I was able to copy/paste and re-submit it. Frustrating.
[quote]Ok, I can conclusively say this has nothing to do with Thread.Sleep().
A trivial example shows this:
Thread1.Run
while true
dim x as integer = 42
wend
Window1.open
Thread1.Run
Pushbutton1.Action
Thread1.Suspend
Result:
Still uses 80% CPU in 2013 R3 even after the thread is Suspended.[/quote]
Using the above example, I can confirm the high CPU usage for suspended threads in when compiling with Xojo 2013r3 on OSX 10.8. For Windows 7x64, Thread.Suspend seems to be working as it should.
Yep, something wrong with the forums.
Were you testing on 1-core or 2+ core CPU for Windows 7? (this may not matter much as 29327 is marked as “fixed” already).
Michael,
I should have stated this was an 8 core Win7x64 machine. The Mac was a 4 core MBP.
Michael,
I have reported problems on semaphores on feedback case #29677 and Xojo Pro channel (Inconsistent semaphore behavior can lead to app crash).
Semaphores works differently if the applications has one or more thread running.
In some cases the main thread can cause an application crash.
The sempahore problem seems not related to R3 but happens also in R2.
Michael,
I have reported problems with sempahore on Xojo Pro channel (Inconsistent semaphore behavior can lead to app crash) and feedback case #29677.
Semaphore behave differently when one or more threads are running.
In some cases the main thread can crash the application when using semaphore.
The problem exist before 2013R3.
[quote=36203:@Maurizio Rossi]Michael,
I have reported problems on semaphores on feedback case #29677 and Xojo Pro channel (Inconsistent semaphore behavior can lead to app crash).Semaphores works differently if the applications has one or more thread running.
In some cases the main thread can cause an application crash.
The sempahore problem seems not related to R3 but happens also in R2.[/quote]
Thanks - I don’t personally use Semaphores, but that seems like another critical bug to get fixed.
This forum works strange when editing…
Sometimes messages get lost or duplicated or…
[quote=36207:@Maurizio Rossi]Michael,
I have reported problems with sempahore on Xojo Pro channel (Inconsistent semaphore behavior can lead to app crash) and feedback case #29677.
Semaphore behave differently when one or more threads are running.
In some cases the main thread can crash the application when using semaphore.
The problem exist before 2013R3.[/quote]
I’m not sure what your expectations are for the example you submitted BUT the bug here actually seems to be that NOT having a secondary thread should also raise an exception since signaling on the main thread & signaling again should lock your app up leaving it with no threads to run - so the scheduler should raise an exception and your app should die.
It’s not doing that.
That IS what is correctly killing the example WITH the secondary thread. All threads are waiting and so there is no “next available thread to run” so you have caused a deadlock in the app and there is NO way to revive it or release the deadlocks. So it dies.
The thread scheduler fails to find anything that can be run so it raises an exception saying “there are no threads that can be run” and the app dies.
Its kind of an odd edge case.
[quote=36207:@Maurizio Rossi]Michael,
I have reported problems with sempahore on Xojo Pro channel (Inconsistent semaphore behavior can lead to app crash) and feedback case #29677.
Semaphore behave differently when one or more threads are running.
In some cases the main thread can crash the application when using semaphore.
The problem exist before 2013R3.[/quote]
Its an odd edge case.
This sample should die in both cases as all threads are ineligible to run.
The bug seems to be that it does NOT die when there are no secondary threads running.
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?
Michael, your example with the Semaphore is almost what I had in mind.
Just one change: Instead of locking (i.e. calling Signal) in the main thread, call it twice in the running thread: Once initially, once when you want to suspend it. Then, in the main thread, where you want to Resume the thread, unlock the Semaphore.
Though, even if that works, I believe it won’t help the issuue with the 100% CPU usage.
Instead, the only work-around for this is to leave the thread’s Run method entirely when you want to suspend, and restart (.Run) it again when you want to resume it. If you have several code points at which you’d Suspend your thread, you’d then have to carry a thread-local state variable that jumps back to the point where you had the Suspend before. I realize that this works only in simple code case but not, for instance, in a more complex scheduler.
curse curse curse
Norman, Thom, anyone from Xojo - can you comment on the feasibility / timing of fixing https://xojo.com/issue/29633 ? If it’s not going to be fixed in 3.1, then I will probably have to spend time trying to come up with workarounds, such as suggested by Thomas and others (instead of sleeping threads, have them exit the Run loop, then have another Event which calls the .Run method again)