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.
  

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.

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
  

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

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

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

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

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

 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

  

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,


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

 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