Jump to content
Posted 24 April 2012 - 04:21 PM
Posted 24 April 2012 - 05:08 PM
Posted 24 April 2012 - 05:37 PM
"Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping."
stop() is deprecated,
Is there any better solution?
Posted 24 April 2012 - 05:43 PM
For very long-running tasks it's important for the user to be able to suspend the process at any given time, and suspend/resume is much better in that respect than destroying and recreating every thread used. If you use the mechanisms provided by your OS (and transparently interfaced by Java) it will work perfectly too.
For what exactly? Threads are created, they run and then terminate. Stopping or otherwise interferring with them has long been abandoned due to problems it causes.
“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”
Posted 24 April 2012 - 06:55 PM
This isn't a good idea (depending on exactly what you mean by built-in suspend resume mechanisms). It you suspend a thread while it has a lock held, that's a great way to bring the rest of your application to a stand-still.
Threads on every platform already have built-in suspend/resume mechanisms, you should those instead of rolling your own.
As ApochPiQ said, primitives such as condition variables and semaphores are the things to use.
For very long-running tasks it's important for the user to be able to suspend the process at any given time.
Posted 25 April 2012 - 07:56 AM
You should not use boolean variables to signal to a thread; that is subject to race conditions and can easily produce undesirable nondeterministic behavior.
Instead, use a thread synchronization primitive such as a condition variable or semaphore to signal when you want your thread to run. This allows the OS to control the thread properly, and will have the added bonus of making your thread consume no CPU resources when it is not active.