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/

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

Presumably you've tried killing the hosted process instead?

"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

"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

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/

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.