|
|
You're in the
dotnet clr
group:System.Threading.Thread
dotnet clr:
When System.Threading.Thread object gets destroyed by GC, does GC
automatically Abort this thread if IsAlive is true, i.e. thread is still running? Thanks,
[quoted text, click to view]
"Amelyan" <bamelyan at wi.rr.com> wrote: > When System.Threading.Thread object gets destroyed by GC, GC doesn't collect Thread objects which are still running. [quoted text, click to view] > does GC > automatically Abort this thread if IsAlive is true, i.e. thread is still > running? -- Barry --
In other words, if don't stop my thread explicitly, it will run
indefinitely, even if no references are pointing at this Thread object. [quoted text, click to view] "Barry Kelly" <barry.j.kelly@gmail.com> wrote in message news:dr48039rfr0uit0bl4poit544v6cf5coh8@4ax.com... > "Amelyan" <bamelyan at wi.rr.com> wrote: > >> When System.Threading.Thread object gets destroyed by GC, > > GC doesn't collect Thread objects which are still running. > >> does GC >> automatically Abort this thread if IsAlive is true, i.e. thread is still >> running? > > -- Barry > > -- > http://barrkel.blogspot.com/
[quoted text, click to view]
<"Amelyan" <bamelyan at wi.rr.com>> wrote: > In other words, if don't stop my thread explicitly, it will run > indefinitely, even if no references are pointing at this Thread object. Absolutely. If it didn't do this, you'd have to make sure you always had a reference to all "child" thread objects, which would often be a real pain. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
What about when the process that created the thread dies, will thread keep
running indefinitely? If so, I would need to restart my machine just to kill this thread? [quoted text, click to view] "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message news:MPG.207224fef39bbf8c98da27@msnews.microsoft.com... > <"Amelyan" <bamelyan at wi.rr.com>> wrote: >> In other words, if don't stop my thread explicitly, it will run >> indefinitely, even if no references are pointing at this Thread object. > > Absolutely. If it didn't do this, you'd have to make sure you always > had a reference to all "child" thread objects, which would often be a > real pain. > > -- > Jon Skeet - <skeet@pobox.com> > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet > If replying to the group, please do not mail me too
[quoted text, click to view]
<"Amelyan" <bamelyan at wi.rr.com>> wrote: > What about when the process that created the thread dies, will thread keep > running indefinitely? If so, I would need to restart my machine just to > kill this thread? The thread is part of the process - if the process dies, the thread will have died too. -- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
[quoted text, click to view]
"Amelyan" <bamelyan at wi.rr.com> wrote in message news:%23fEL4sVcHHA.4820@TK2MSFTNGP06.phx.gbl... > What about when the process that created the thread dies, will thread keep running > indefinitely? If so, I would need to restart my machine just to kill this thread? > The process is removed after all of it's threads are removed, when the OS can't remove a thread from a process (there are rare occasions in which this can happen), then the process will not die. Willy.
I believe you will have to set
IsBackground = true then in .NET when the main process thread dies, it will cleanup the threads marked as background. Patrick van Dijk http://www.spatial-eye.com/ [quoted text, click to view] On Mar 28, 7:04 pm, "Amelyan" <bamelyan at wi.rr.com> wrote: > What about when the process that created the thread dies, will thread keep > running indefinitely? If so, I would need to restart my machine just to > kill this thread? > > "Jon Skeet [C# MVP]" <s...@pobox.com> wrote in messagenews:MPG.207224fef39bbf8c98da27@msnews.microsoft.com... > > > <"Amelyan" <bamelyan at wi.rr.com>> wrote: > >> In other words, if don't stop my thread explicitly, it will run > >> indefinitely, even if no references are pointing at this Thread object. > > > Absolutely. If it didn't do this, you'd have to make sure you always > > had a reference to all "child" thread objects, which would often be a > > real pain. > > > -- > > Jon Skeet - <s...@pobox.com> > >http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet > > If replying to the group, please do not mail me too
Are you talking about native threads or .NET threads?
What are these rare occasions? [quoted text, click to view] "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message
news:uti8Y4YcHHA.3644@TK2MSFTNGP02.phx.gbl... > The process is removed after all of it's threads are removed, when the OS > can't remove a thread from a process (there are rare occasions in which > this can happen), then the process will not die.
[quoted text, click to view]
"bazad" <no reply> wrote in message Hmmm what are .NET threads?news:2960C265-508C-4F59-9C11-21FD6CE1D866@microsoft.com... > Are you talking about native threads or .NET threads? > Framework Threads are mapped to OS threads, the active component in a process is an OS thread, the OS doesn't know anything about what you call ".NET threads". [quoted text, click to view] > What are these rare occasions? The rare occasions are when threads actually ignore the request to abort when they actually > execute kernel code (say - buggy driver code). Such threads can't be cleaned-up and as result the process stays in the process table, they go away only at system reboot. Willy.
[quoted text, click to view] "Günter Prossliner" <g.prossliner/gmx/at> wrote in message news:eeQhQVUdHHA.1240@TK2MSFTNGP04.phx.gbl... > Hi Willy! > >> The rare occasions are when threads actually ignore the request to >> abort when they actually execute kernel code > > While this is absolutly true... > > (say - buggy driver code) > > ... the word "buggy" may be misleading here. Try to abort a thread (even > with the unmanged "TerminateThread" API), which is waiting for some data > from a Socket (sync operation). No chance, but I won't call the code > buggy. It is a bad driver design, which was finally fixed in Vista (see discussions of CancelIoEx).
[quoted text, click to view] "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message news:epScemRdHHA.284@TK2MSFTNGP05.phx.gbl... > "bazad" <no reply> wrote in message > news:2960C265-508C-4F59-9C11-21FD6CE1D866@microsoft.com... >> Are you talking about native threads or .NET threads? >> > Hmmm what are .NET threads? > Framework Threads are mapped to OS threads, the active component in a > process is an OS thread, the OS doesn't know anything about what you call > ".NET threads". In the current runtime, yes. But .NET makes no guarantee that .NET threads (or Framework threads as you call them, or managed threads, or etc) map to OS thread, only that .NET threads act like thread of execution and that .NET ThreadLocalAttribute applies to .NET threads.
Hi Willy!
[quoted text, click to view] > The rare occasions are when threads actually ignore the request to > abort when they actually execute kernel code While this is absolutly true... (say - buggy driver code) .... the word "buggy" may be misleading here. Try to abort a thread (even with the unmanged "TerminateThread" API), which is waiting for some data from a Socket (sync operation). No chance, but I won't call the code buggy. GP
[quoted text, click to view]
"Ben Voigt" <rbv@nospam.nospam> wrote in message news:u30j0rVdHHA.4012@TK2MSFTNGP03.phx.gbl... > > "Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message > news:epScemRdHHA.284@TK2MSFTNGP05.phx.gbl... >> "bazad" <no reply> wrote in message >> news:2960C265-508C-4F59-9C11-21FD6CE1D866@microsoft.com... >>> Are you talking about native threads or .NET threads? >>> >> Hmmm what are .NET threads? >> Framework Threads are mapped to OS threads, the active component in a process is an OS >> thread, the OS doesn't know anything about what you call ".NET threads". > > In the current runtime, yes. But .NET makes no guarantee that .NET threads (or Framework > threads as you call them, or managed threads, or etc) map to OS thread, only that .NET > threads act like thread of execution and that .NET ThreadLocalAttribute applies to .NET > threads. > Right, but you are referring to the (un-finished/failed) attempt of the CLR team to introduce fibers in the CLR, unfortunately support for fibers was cancelled, and AFIAK there are no plans to introduce them anytime soon. The SQL team was the one that requested this feature, but finally they gave up waiting and they implemented this in the SQL unmanaged hosting code. Anyway, even when fibers (which run in the context of a thread), ever gets stuck in a "badly behaving kernel component", then it's thread won't die either when ordered to abort. I prefer not to talk .NET, this is a marketing term that covers nothing we are discussing here, I prefer to talk about the CLR and/or the Framework, that's why I asked what was meant with .NET threads, such things don't exist, really. Willy.
[quoted text, click to view]
"Günter Prossliner" <g.prossliner/gmx/at> wrote in message news:eeQhQVUdHHA.1240@TK2MSFTNGP04.phx.gbl... > Hi Willy! > >> The rare occasions are when threads actually ignore the request to >> abort when they actually execute kernel code > > While this is absolutly true... > > (say - buggy driver code) > > ... the word "buggy" may be misleading here. Try to abort a thread (even with the unmanged > "TerminateThread" API), which is waiting for some data from a Socket (sync operation). No > chance, but I won't call the code buggy. > > > GP > Don't know what OS version you have this on, but I can't remember having a socked (Winsock) blocked waiting for IO completion to be not honoring the abort on NT4 and higher. Willy.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |