Threading ...

  • Thread starter Thread starter ron
  • Start date Start date
R

ron

If I use the System.Threading.ThreadPool.QueueUserWorkItem to spawn a new
threaded process, will this process be executed regardless of whether or not
the current process ends prior to completion of the child thread? Or do I
need to create a new thread object and join it to my current thread in order
to guarantee execution of code in a child process?

-Ron
 
If you successfully start a process by using
System.Diagnostics.Process.Start() method then it will execute regardless of
what the code that started it does. It is a separate process, not a child
process of the process that created it.
 
Threads started under the System.Threading.Thread class
cannot be included in a new process under the
System.Diagnostics.Process. Instead you need to use the
System.Diagnostics.ProcessThread class. This doesn't work
for me under the current architecture. I'll likely need
to join to the current thread in order to guarantee
execution.

-Ron
-----Original Message-----
If you successfully start a process by using
System.Diagnostics.Process.Start() method then it will execute regardless of
what the code that started it does. It is a separate process, not a child
process of the process that created it.
Click to expand...
System.Threading.ThreadPool.QueueUserWorkItem to spawn a
new
 
If you want to start a unit of execution within the same managed process
then use a System.Threading.Thread - this creates a managed thread within
the same process. You can then use thread.Join to wait for that thread to
complete. If it's not one of your threads (e.g. a threadpool) then you can
use an event to signal the completion of the work, and then use
WaitOne(event) in the main thread to wait for it to complete.

If you want more isolation you can create another appdomain and run it in
that appdomain. You can also run an executable in another appdomain using
appDomain.ExecuteAssembly(assemblyPath), where appDomain is a reference to
another appdomain.

You can also use a named mutex for interprocess signalling. You can launch
another process, win32 or managed code, and when that code completes it sets
a mutex to the signalled state. The launching program can wait for that
mutex to be signalled.

It's not clear to me what you are trying to accomplish so it's not possible
to determine what the best approach would be.
 
Back
Top