Re: Why could a suspended thread leak?
- From: beginwithl@xxxxxxxxx
- Date: Mon, 2 Feb 2009 15:39:38 -0800 (PST)
hi Pete
On Feb 3, 4:03 am, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
On Mon, 02 Feb 2009 14:12:49 -0800, <beginwi...@xxxxxxxxx> wrote:
[...]
"Or if you're maintaining state in some sort of data structure
that is reachable even without the thread executing, a similar thing
could
happen. "
* So with “is reachable even without the thread executing” you were
referring to objects “local” ( thus no other thread references them )
to the aborted/suspended thread, which ( even though there are no
longer any references to them ) are still somehow reachable?
No, I'm referring to objects reachable via some other data structure.
It would be useful for you to not mix "aborted" and "suspended". Those
are two very different scenarios, and you can't really apply the same
reasoning to each.
For aborted threads, the stack goes away. Local variables no longer
exist, so the only way an object referenced by the thread could still be
reachable is if there's a reference somewhere else. Such in a static
variable, or some data structure that is itself referenced (directly or
indirectly) by a static variable.
So if thread T1 wasn’t aborted, then T1 would be able to somehow
manage to make the object to become unreachable ( when not wanted
anymore )?
But if thread is aborted, then that may not happen and thus object is
still reachable ( app still references it via some static variable
or… ) even when not needed/wanted anymore? And that is considered a
leak
For suspended threads, the stack remains. Objects remain reachable simply > by virtue of being referenced even simply within the stack as local
variables. If a thread had a reference to an object before it's
suspended, it continues to have a reference to the object after it's
suspended.
And why would that be considered a problem ( why would we call it
leaking )? Thread will simply “make” object unreachable when it is
resumed?!
The reason you don't know the state of the thread when using Abort() or
Suspend() is that there's nothing that would let your code know what
instruction the thread being aborted or suspended is executing. Keeping
in mind also that the thread executes instructions, not statements, so
you
could even wind up aborting or suspending a thread mid-statement.
* But if thread only gets aborted/suspended when it executes Abort/
Suspend statement,
False predicate results in a trivially true "if/then" statement.
In other words, it's simply not true that a "thread only get
aborted/suspended when it executes Abort()/Suspend() statement". In fact,
the only interesting uses of those methods is when they are called by a
thread other than the one being aborted or suspended.
And hopefully with that, you understand why using those methods can result
in unpredictable results.
yep :)
thank you
.
- Follow-Ups:
- Re: Why could a suspended thread leak?
- From: Peter Duniho
- Re: Why could a suspended thread leak?
- References:
- Re: Why could a suspended thread leak?
- From: beginwithl
- Re: Why could a suspended thread leak?
- From: Peter Duniho
- Re: Why could a suspended thread leak?
- From: beginwithl
- Re: Why could a suspended thread leak?
- From: Peter Duniho
- Re: Why could a suspended thread leak?
- From: beginwithl
- Re: Why could a suspended thread leak?
- From: Peter Duniho
- Re: Why could a suspended thread leak?
- Prev by Date: Re: Backgroundworker
- Next by Date: Re: Set up default folder
- Previous by thread: Re: Why could a suspended thread leak?
- Next by thread: Re: Why could a suspended thread leak?
- Index(es):
Relevant Pages
|