ThreadPool.QueueUserWorkItem

[Guest]

Hi,

I'm looking to build an application that fires off a number of processes. I
have created a class (process wrapper) that contains an instance of a Process
and some associated information like a friendly name, enum flag for status
(e.g. started, not started etc). This class will manage the state for the
process it encapsulates.

I use ThreadPool.QueueUserWorkItem to call Start on each of my process
wrapper classes which in turn calls start on the process and say creates an
instance of notepad. My question is if I hook up to some events that my
wrapper class raises during the WaitCallback does this stop the worker thread
being returned to the thread pool? Lets say after 15 mins the Wrapper process
raises one of the events I want to know about this and act accordingly.

 

[Peter Duniho]

Hi,

I'm looking to build an application that fires off a number of processes. I
have created a class (process wrapper) that contains an instance of a Process
and some associated information like a friendly name, enum flag for status
(e.g. started, not started etc). This class will manage the state for the
process it encapsulates.

I use ThreadPool.QueueUserWorkItem to call Start on each of my process
wrapper classes which in turn calls start on the process and say creates an
instance of notepad. My question is if I hook up to some events that my
wrapper class raises during the WaitCallback does this stop the worker thread
being returned to the thread pool? Lets say after 15 mins the Wrapper process
raises one of the events I want to know about this and act accordingly.

It's not clear, since you provided no code, what the Start method passed
as the WaitCallback to QueueUserWorkItem actually does. If it returns
immediately after starting the process, then no...it doesn't stop the
worker thread from being returned to the thread pool.

On the other hand, if the Start method doesn't return, but instead sits
and waits on the process for some reason for the purpose of raising the
events you're talking about, then yes...that would prevent the worker
thread from being returned to the thread pool, since the Start method is
continuing to execute, requiring the thread used to execute it to remain
assigned to that task.

Note that none of this really has anything to do with hooking up events.
The act of subscribing to an event wouldn't cause this. The real
question is only whether the method you pass to QueueUserWorkItem
returns or not. Until it returns, the thread pool thread used to
service that work item is unavailable for doing anything else.

Pete

 

[Guest]

Thanks Peter. I've posted some code below but from what I understand I will
return immediately and the thread will not be blocked. What does this mean
for event notification though, I assume that I will not be thread safe
because the OnProcessStateChanged handler below will be executed on a
available worker thread rather than the main thread?

public enum ProcessState { started, stopped, notstarted }
internal delegate void OnProcessStateChangedHandler(ProcessWrapper
processWrapper, ProcessState oldState, ProcessState state);

public class ProcessWrapper
{
public Process _process;
public ProcessState _processState;
public event OnProcessStateChangedHandler OnProcessStateChanged;

public ProcessWrapper()
{
_processState = ProcessState.notStarted;
}

public void Start()
{
_process = Process.Start("notepad.exe");
_process.EnableRaisingEvents = true;
_process.Exited += new EventHandler(_process_Exited);
_processState = ProcessState.started;

if (OnProcessStateChanged != null)
{
OnProcessStateChanged(this, ProcessState.notstarted,
ProcessState.started);
}
}

void _process_Exited(object sender, EventArgs e)
{
if (OnProcessStateChanged != null)
{
OnProcessStateChanged(this, ProcessState.started,
ProcessState.stopped);
}
}
}

static void Main(string[] args)
{
ProcessWrapper process = new ProcessWrapper();
ThreadPool.QueueUserWorkItem(new WaitCallback(StartProcess),process );

process.OnProcessStateChanged += new
OnProcessStateChangedHandler(process_OnProcessStateChanged);

}

private static void StartProcess(object state)
{
ProcessWrapper process = state as ProcessWrapper;
process.Start();
}

static void process_OnProcessStateChanged(ProcessEntry entry, ProcessState
oldState, ProcessState state)
{
//Do something, is this thread safe?
}

 

[Peter Duniho]

Thanks Peter. I've posted some code below but from what I understand I will
return immediately and the thread will not be blocked. What does this mean
for event notification though, I assume that I will not be thread safe
because the OnProcessStateChanged handler below will be executed on a
available worker thread rather than the main thread?

That depends on what you do in the handler. You are right, the handler
will be executed on other than the main thread. That means that the
question of thread safety exists, but does not tell you whether the
method is thread safe or not.

The thread can be thread safe if it does not access data used by other
threads. It can also be thread safe if it does access data used by
other threads, but has some mechanism for ensuring synchronization of
that data.

Pete