In order for an class instance to be agile(allowed to flow between AD's)
it must not (amongst other rules) refer to > instances that are not agile,
this is clearly not the case for the Thread class who refers to managed
thread local
After I wrote the previous message my memory was tickled by something along
these lines I had read on Chris Brumme's blog. I was incorrect about the
Thread object being marshalled by value; it is indeed marshalled by bleed.
However, my main point remains unchanged. Here's a quote from Chris... "In
other cases, we absolutely require that an instance marshal by bleed.
System.Threading.Thread is a good example of this. The same managed thread
can freely call between AppDomains. Since the current marshaler cannot
guarantee that an instance will always bleed, we have made Thread
unmarshalable by the marshaler for now. Then the CLR bleeds it without
using the marshaler when you call Thread.CurrentThread"
....
"An agile instance must necessarily be of a type we loaded as
domain-neutral. However, the converse is not true. The vast majority of
domain-neutral types do not have agile instances.
If an instance marshals-by-bleed or if it performs identity-preserving
marshal-by-value, then by definition it is agile. The effect is the same in
both cases: it's possible to have direct references to the same instance
from multiple AppDomains"
This contradicts your statement - he states that a thread object is
marshalled-by-bleed and is agile.
However each managed threads can freely call into a remote application
domain and they must do this as quickly >as possible therefore they are
treated very carefully by the CLR. When a managed thread calls into
another AD and >the target calls Thread.CurrentThread the CLR will bleed
certain Thread properties like Hashcode, Name, Priority >etc. without using
a marshaller (MSFT calls this Marshall by bleeding, in fact the target gets
a reference to the >original Thread object but access is controlled by the
CLR), other properties like the soft thread TLS however
I still don't agree that a managed thread is bounded by an appdomain. I
agree that there are some components of the thread object that are AD bound,
but this does not mean that the thread itself is AD bound, only that some of
the thread's state must be partitioned by appdomain. An example of this are
statics, which can be per-AD, per-thread, per-Context or per-process.
Further, a thread is a repository for a great deal of information that go
far beyond managed properties such as hashcodes and names. The most
important of these is the stack. The stack must record all sorts of things,
such as exception records, appdomain transitions, and execution engine
frames (e.g. ContextTransition, Exception, PInvokeCall, etc). A thread may
wander between AppDomains, managed and unmanged code, etc., and all these
transitions are recorded on the stack. The execution engine needs to track
these for purposes such as updating stack-stored object references for the
GC, hold state for security checks, recognize transitions between AD and
managed/unmanaged code, finding handlers for stack unwinding during an
exception, etc.
It may be theoretically possible to build an execution engine that keeps
threads bounded to a single appdomain yet maintains a consistent state
across multiple appdomains, but I don't believe that is the way it was
implemented. Stack-walking would be incredibly inefficient (and error-prone)
if it had to access multiple thread objects. It would be far simpler to have
a single managed thread object that tracked all this information, and then
created objects per-instance, or allowed the CLR to control access to, those
fields that need to remain bounded to an AD.
Dave
