473,287 Members | 1,492 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

how can i create new thread in the new appdomain ?

in win32 process , when u create new process,u have new main thread.

i know,appDomain r logical procces,that exists in 1 win32 process.

the q:
is there way to create second appDomain (the first 1 is the defualt
appDomain) with his new ("main") thread ?

if not ,what is the easy and clear way to create new thread on the new
appDomain ?
Jul 19 '05 #1
4 6160
[Quick comment - I know *I* would find it easier to read your posts if
you used full English words like "you" and "are" rather than "u" and
"r". I don't know if anyone else agrees with me, admittedly, but
technical newsgroups don't tend to use this style of writing, in my
experience.]

Daylor <Da****@012.net.il> wrote:
in win32 process , when u create new process,u have new main thread.

i know,appDomain r logical procces,that exists in 1 win32 process.
It's not quite that simple. AppDomains are logically separate in terms
of the objects etc, but threads can traverse AppDomains.
the q:
is there way to create second appDomain (the first 1 is the defualt
appDomain) with his new ("main") thread ?
I don't believe .NET has any concept of the "main" thread. There are
foreground threads and background threads - that's all. (I could be
wrong though - and I'm sure COM affects things, with apartments etc.)
if not ,what is the easy and clear way to create new thread on the new
appDomain ?


You don't really create threads "on" an AppDomain. You just create
threads, and they run code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Jul 19 '05 #2
>
About threads crossing application domains, you need to make a clear distinction between hard threads (OS threads) and soft threads (CLR threads) here.
While hard threads don't have application domain affinity (they are not tied to a specific application domain), CLR threads do have this affinity so they cannot cross AD. borders.

Willy.

The information that I have read indicates that CLR threads are not bounded
to a single appdomain. I agree that there is a distinction between OS
threads and CLR threads. A CLR thread is an object that is mapped to an OS
thread, that the mapping between a CLR thread and an OS thread can change,
and an OS thread can be mapped to different CLR thread objects at different
times. However, this is an implementation detail of the current version of
the CLR and may change in the future (e.g. if the CLR ever implements
threading on top of fibers instead of OS threads). I disagree that CLR
threads are bounded by AD borders.

Here is a direct quote from the documentation of the Thread class:
"GetHashCode provides identification for managed threads. For the lifetime
of your thread, it will not collide with the value from any other thread,
regardless of the application domain from which you obtain the value.
Note An operating-system ThreadId has no fixed relationship to a managed
thread, because an unmanaged host can control the relationship between
managed and unmanaged threads. Specifically, a sophisticated host can use
the CLR Hosting API to schedule many managed threads against the same
operating system thread, or to move a managed thread between different
operating system threads."

This clearly implies that the thread of execution can cross appdomain
boundaries. Now, it may be that the CLR thread object is bounded in the
sense that because it is not derived from MarshalByRefObj a direct reference
to that object cannot be passed to another appdomain (a copy of the object
such that a new copy that preserves the original identity would be used in
the other appdomain). However, this is not the same thing as the current
thread of execution.

These details are of interest to those of us that like to know what is going
on below the surface; managed code almost never needs to know about this.
From the perspective of an application a sequence of instructions is
executed on a logical thread and the logical thread can cross appdomain
boundaries and preserve its CLR identity.

If my understanding of this is incorrect then please provide more
information.

Dave

Jul 19 '05 #3
Dave wrote:
||| About threads crossing application domains, you need to make a clear
|| distinction between hard threads (OS threads) and soft threads
||| (CLR threads) here.
||| While hard threads don't have application domain affinity (they are
||| not
|| tied to a specific application domain), CLR threads do have
||| this affinity so they cannot cross AD. borders.
|||
||| Willy.
|||
||
||
|| The information that I have read indicates that CLR threads are not
|| bounded to a single appdomain. I agree that there is a distinction
|| between OS threads and CLR threads. A CLR thread is an object that
|| is mapped to an OS thread, that the mapping between a CLR thread and
|| an OS thread can change, and an OS thread can be mapped to different
|| CLR thread objects at different times. However, this is an
|| implementation detail of the current version of the CLR and may
|| change in the future (e.g. if the CLR ever implements threading on
|| top of fibers instead of OS threads). I disagree that CLR threads
|| are bounded by AD borders.
||
|| Here is a direct quote from the documentation of the Thread class:
|| "GetHashCode provides identification for managed threads. For the
|| lifetime of your thread, it will not collide with the value from any
|| other thread, regardless of the application domain from which you
|| obtain the value. Note An operating-system ThreadId has no fixed
|| relationship to a managed thread, because an unmanaged host can
|| control the relationship between managed and unmanaged threads.
|| Specifically, a sophisticated host can use the CLR Hosting API to
|| schedule many managed threads against the same operating system
|| thread, or to move a managed thread between different operating
|| system threads."
||
|| This clearly implies that the thread of execution can cross appdomain
|| boundaries. Now, it may be that the CLR thread object is bounded in
|| the sense that because it is not derived from MarshalByRefObj a
|| direct reference to that object cannot be passed to another
|| appdomain (a copy of the object such that a new copy that preserves
|| the original identity would be used in the other appdomain).
|| However, this is not the same thing as the current thread of
|| execution.
||
|| These details are of interest to those of us that like to know what
|| is going on below the surface; managed code almost never needs to
|| know about this. From the perspective of an application a sequence
|| of instructions is executed on a logical thread and the logical
|| thread can cross appdomain boundaries and preserve its CLR identity.
||
|| If my understanding of this is incorrect then please provide more
|| information.
||
|| Dave
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 storage (TLS). 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
remain AD bound.

Willy.
Jul 19 '05 #4
>
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 storage (TLS).
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 remain AD bound.


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
Jul 19 '05 #5

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Daylor | last post by:
can i do it this way : from the defualt AppDomain : create thread. from the start function of the new thread , create new AppDomain,and then create my class through the AppDomain . this way...
7
by: Daylor | last post by:
in win32 process , when u create new process,u have new main thread. i know,appDomain r logical procces,that exists in 1 win32 process. the q: is there way to create second appDomain (the...
3
by: Keyee Hsu | last post by:
Hi, I have a C# app that creates an AppDomain, enters it, and spawns an asyn thread to do some work and then block itself. Upon the completion of the work, the async thread supposedly terminates,...
20
by: Doug Thews | last post by:
I ran into an interesting re-pain delay after calling the Abort() method on a thread, but it only happens the very first time I call it. Every time afterward, there is no delay. I've got a...
5
by: Nak | last post by:
Hi there, I have a very simple console application that I'm trying to handle the thread exception on, as I understand it there is no Application object available to a console application, so I...
2
by: Artem | last post by:
When I use the method Thread.Abort, it only sends a request of aborting to OS to stop a thread. The thread itself isn't killed and allocated resources aren't released. I tried to run that thread...
4
by: illegal.prime | last post by:
Hi all, I'm getting unexpected results when trying to preload assemblies into an AppDomain I'm creating. Upon creation of the AppDomain - I attach an AssemblyResolve to both my current AppDomain...
0
by: jeremyje | last post by:
I would like to create an application where I have many concurrent processes being managed by a monitoring process. Each process that is "managed" will be invoked from an assembly dll (think...
1
by: Polaris | last post by:
Hi C# Experts: I have 2 threads and I like to run them in seperate AppDomains. In other words, I want to start 2 new AppDomains and then run a thread within each of the AppDomains. How to do...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.