D - std.thread terminate
- J Anderson <REMOVEanderson badmama.com.au> Apr 19 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 19 2004
- J Anderson <REMOVEanderson badmama.com.au> Apr 19 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 19 2004
- J Anderson <REMOVEanderson badmama.com.au> Apr 20 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 20 2004
- J Anderson <REMOVEanderson badmama.com.au> Apr 20 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 20 2004
- J Anderson <REMOVEanderson badmama.com.au> Apr 20 2004
- Stewart Gordon <smjg_1998 yahoo.com> Apr 20 2004
- "Phill" <phill pacific.net.au> Apr 19 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 19 2004
- J Anderson <REMOVEanderson badmama.com.au> Apr 20 2004
- "Kris" <someidiot earthlink.dot.dot.dot.net> Apr 20 2004
- "Phill" <phill pacific.net.au> Apr 20 2004
- "Phill" <phill pacific.net.au> Apr 20 2004
Can we have a terminate thread method for std.thread please? Or parhaps we could go: Thread thread; ... delete thread; -- -Anderson: http://badmama.com.au/~anderson/
Apr 19 2004
No offense intended, but I'd like to suggest extreme caution over such notions. There are some truly thorny issues with killing a thread, as there are with pause() and resume(). In fact, I'd argue strongly that the latter two be *removed* from std.Thread because they're inherently deadlock-prone. Here's why the Java SDK folks tossed this particular trinity out the proverbial window: http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.ht ml FWIW, I'd like to see std.Thread grow and mature via a solid adoption of Doug Lea's experience and open-source libraries. Anyone with sufficient expertise to effectively manage the real MT issues around said trinity would presumably also be an ideal candidate to port Professor Lea's code instead <g> - Kris "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c622qn$31ih$3 digitaldaemon.com...Can we have a terminate thread method for std.thread please? Or parhaps we could go: Thread thread; ... delete thread; -- -Anderson: http://badmama.com.au/~anderson/
Apr 19 2004
Kris wrote:No offense intended, but I'd like to suggest extreme caution over such notions.
too (the source code that is), ie like in a debugger. -- -Anderson: http://badmama.com.au/~anderson/
Apr 19 2004
At that level, perhaps you might make an arrangement to get the native thread-handle. The std.Thread module appears to expose this as the 'hdl' field (under Win32) - Kris "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c627p4$avg$1 digitaldaemon.com...Kris wrote:No offense intended, but I'd like to suggest extreme caution over such notions.
too (the source code that is), ie like in a debugger. -- -Anderson: http://badmama.com.au/~anderson/
Apr 19 2004
Kris wrote:At that level, perhaps you might make an arrangement to get the native thread-handle. The std.Thread module appears to expose this as the 'hdl' field (under Win32) - Kris
because it's in debug mode."J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c627p4$avg$1 digitaldaemon.com...Kris wrote:No offense intended, but I'd like to suggest extreme caution over such notions.
too (the source code that is), ie like in a debugger. -- -Anderson: http://badmama.com.au/~anderson/
-- -Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
Sorry JA, wish I could help you with that one. Perhaps one of the DigDug guys can help you out? (unless this is for DigDug :-) - Kris "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c62igb$1214$1 digitaldaemon.com...Kris wrote:At that level, perhaps you might make an arrangement to get the native thread-handle. The std.Thread module appears to expose this as the 'hdl' field (under Win32) - Kris
because it's in debug mode."J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c627p4$avg$1 digitaldaemon.com...Kris wrote:No offense intended, but I'd like to suggest extreme caution over such notions.
too (the source code that is), ie like in a debugger. -- -Anderson: http://badmama.com.au/~anderson/
-- -Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
Kris wrote:Sorry JA, wish I could help you with that one. Perhaps one of the DigDug guys can help you out? (unless this is for DigDug :-) - Kris
-- -Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message > Yeah its for digdug. Presumably you've tried killing the hosted process instead?
Apr 20 2004
J Anderson <REMOVEanderson badmama.com.au> Kris wrote:"J Anderson" <REMOVEanderson badmama.com.au> wrote in message > Yeah its for digdug. Presumably you've tried killing the hosted process instead?
time of the WaitForDebugEvent and poll it every so often for a way out, but it doesn't seem to let me stop without error. The user should be able to stop the process if something starts to go criticly wrong or they wish to start again. -- -Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
Kris wrote:No offense intended, but I'd like to suggest extreme caution over such notions. There are some truly thorny issues with killing a thread, as there are with pause() and resume(). In fact, I'd argue strongly that the latter two be *removed* from std.Thread because they're inherently deadlock-prone. Here's why the Java SDK folks tossed this particular trinity out the proverbial window: http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
That's being a bit idealistic I think. My guess is that pause and resume are, like delete, designed for programmers who know what they're doing, i.e. that they can be sure the way they're using it isn't going to lead to a deadlock. Maybe, if pause and resume are going to be kept, there should be a "use with caution" note in the docs. Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Apr 20 2004
Great topic!
Given this piece of code does a Thread terminate at the return of the
method, or what is the status of the Thread after returning from the method?
int main()
{
Thread t1 = new Thread(&amethod);
t1.start();
return 0;
}
int amethod()
{
//do somthing spectacular
return 0;
}
Phill.
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c622qn$31ih$3 digitaldaemon.com...
Can we have a terminate thread method for std.thread please? Or parhaps
we could go:
Thread thread;
...
delete thread;
--
-Anderson: http://badmama.com.au/~anderson/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
Apr 19 2004
Your example has a race-condition Phil ... not the usual bogus variety, but one in terms of how soon your t1 thread is killed ... main() effectively quits right after starting up the thread (I imagine that was deliberate). If you t1.thread gets a sufficient timeslice and returns completely, it will be in a 'terminated' state at that point in time. On the other hand, if main() gets more of a timeslice, the entire process is likely to be killed (including the t1 thread). I believe some runtime environments dictate that the process should keep running at that point and, as such, treat any running threads as Daemons. Other environments permit specific control over this by enabling the programmer to determine whether a thread should be considered a Daemon or not (IMHO, D should follow the latter model). While terminating the process is somewhat of a special-case (all resources are typically freed up by the OS), killing a thread before *it* has decided to terminate is usually poor form. Imagine, if you will, that the thread has gained access to some remote resource that the OS doesn't know about; perhaps something attached to the serial port ... by killing the thread prematurely you effectively leave the remote device in an unknown state, and it's likely going to need a reset before it can be accessed again. - Kris "Phill" <phill pacific.net.au> wrote in message news:c62e74$otm$1 digitaldaemon.com...Great topic! Given this piece of code does a Thread terminate at the return of the method, or what is the status of the Thread after returning from the
int main() { Thread t1 = new Thread(&amethod); t1.start(); return 0; } int amethod() { //do somthing spectacular return 0; } Phill. "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c622qn$31ih$3 digitaldaemon.com...Can we have a terminate thread method for std.thread please? Or parhaps we could go: Thread thread; ... delete thread; -- -Anderson: http://badmama.com.au/~anderson/
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
Apr 19 2004
Kris wrote:Your example has a race-condition Phil ... not the usual bogus variety, but one in terms of how soon your t1 thread is killed ... main() effectively quits right after starting up the thread (I imagine that was deliberate). If you t1.thread gets a sufficient timeslice and returns completely, it will be in a 'terminated' state at that point in time. On the other hand, if main() gets more of a timeslice, the entire process is likely to be killed (including the t1 thread). I believe some runtime environments dictate that the process should keep running at that point and, as such, treat any running threads as Daemons. Other environments permit specific control over this by enabling the programmer to determine whether a thread should be considered a Daemon or not (IMHO, D should follow the latter model). While terminating the process is somewhat of a special-case (all resources are typically freed up by the OS), killing a thread before *it* has decided to terminate is usually poor form. Imagine, if you will, that the thread has gained access to some remote resource that the OS doesn't know about; perhaps something attached to the serial port ... by killing the thread prematurely you effectively leave the remote device in an unknown state, and it's likely going to need a reset before it can be accessed again. - Kris
constantly challengers you to kill processors, at least once every two days <g>/ -- -Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message > Yeah but a lot of threads you know basicly what they do. I mean, winxpconstantly challengers you to kill processors, at least once every two days <g>/
Right :-) Wonder why that is?
Apr 20 2004
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:c62im5$1214$2 digitaldaemon.com...Kris wrote:Your example has a race-condition Phil ... not the usual bogus variety,
one in terms of how soon your t1 thread is killed ... main() effectively quits right after starting up the thread (I imagine that was deliberate). If you t1.thread gets a sufficient timeslice and returns completely, it
be in a 'terminated' state at that point in time. On the other hand, if main() gets more of a timeslice, the entire process is likely to be
(including the t1 thread). I believe some runtime environments dictate
the process should keep running at that point and, as such, treat any running threads as Daemons. Other environments permit specific control
this by enabling the programmer to determine whether a thread should be considered a Daemon or not (IMHO, D should follow the latter model). While terminating the process is somewhat of a special-case (all
are typically freed up by the OS), killing a thread before *it* has
to terminate is usually poor form. Imagine, if you will, that the thread
gained access to some remote resource that the OS doesn't know about; perhaps something attached to the serial port ... by killing the thread prematurely you effectively leave the remote device in an unknown state,
it's likely going to need a reset before it can be accessed again. - Kris
constantly challengers you to kill processors, at least once every two days <g>/
at the very least, id say! Phill. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
Apr 20 2004
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message news:c62fhs$r7s$1 digitaldaemon.com...Your example has a race-condition Phil ... not the usual bogus variety,
one in terms of how soon your t1 thread is killed ... main() effectively quits right after starting up the thread (I imagine that was deliberate).
Yep that was deliberate, to make a simple example. BTW, if I remember correctly, Sun made their Thread's "stop" and "suspend" methods deprecated, for the same reasons that you mention. Thanks ! Phill.If you t1.thread gets a sufficient timeslice and returns completely, it
be in a 'terminated' state at that point in time. On the other hand, if main() gets more of a timeslice, the entire process is likely to be killed (including the t1 thread). I believe some runtime environments dictate
the process should keep running at that point and, as such, treat any running threads as Daemons. Other environments permit specific control
this by enabling the programmer to determine whether a thread should be considered a Daemon or not (IMHO, D should follow the latter model). While terminating the process is somewhat of a special-case (all resources are typically freed up by the OS), killing a thread before *it* has
to terminate is usually poor form. Imagine, if you will, that the thread
gained access to some remote resource that the OS doesn't know about; perhaps something attached to the serial port ... by killing the thread prematurely you effectively leave the remote device in an unknown state,
it's likely going to need a reset before it can be accessed again. - Kris "Phill" <phill pacific.net.au> wrote in message news:c62e74$otm$1 digitaldaemon.com...Great topic! Given this piece of code does a Thread terminate at the return of the method, or what is the status of the Thread after returning from the
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
Can we have a terminate thread method for std.thread please? Or
we could go: Thread thread; ... delete thread; -- -Anderson: http://badmama.com.au/~anderson/
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004
Apr 20 2004