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/

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/

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/

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

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/

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

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/

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/

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/

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