www.digitalmars.com         C & C++   DMDScript  

D - std.thread terminate

reply J Anderson <REMOVEanderson badmama.com.au> writes:
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
next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Kris wrote:


No offense intended, but I'd like to suggest extreme caution over such
notions.
  


I agree in part.  How would you terminate a thread you don't have access 
too (the source code that is), ie like in a debugger.

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 19 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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.


 I agree in part.  How would you terminate a thread you don't have access
 too (the source code that is), ie like in a debugger.

 --
 -Anderson: http://badmama.com.au/~anderson/
Apr 19 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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
  


Actually I tried TerminateThread with hdl, but it crashes.  Parhaps it's 
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.


      


I agree in part.  How would you terminate a thread you don't have access
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
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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


 Actually I tried TerminateThread with hdl, but it crashes.  Parhaps it's
 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.


I agree in part.  How would you terminate a thread you don't have access
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
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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
  


Yeah its for digdug.

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"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
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Kris wrote:


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message > Yeah its for
digdug.

Presumably you've tried killing the hosted process instead?
  


Yeah, but I've probably did something wrong.  I tried taking infinite 
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
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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


<snip>

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
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
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
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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


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
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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

  


Yeah but a lot of threads you know basicly what they do.  I mean, winxp 
constantly challengers you to kill processors, at least once every two 
days <g>/

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 20 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message > Yeah but a
lot of threads you know basicly what they do.  I mean, winxp

 constantly challengers you to kill processors, at least once every two
 days <g>/


Right :-)

Wonder why that is?
Apr 20 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
"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,




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


 Yeah but a lot of threads you know basicly what they do.  I mean, winxp
 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
prev sibling parent "Phill" <phill pacific.net.au> writes:
"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,


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).


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


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


 method?

 "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





---
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