> Hi,
>
[quoted text clipped - 10 lines]
> 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
JT - 24 Oct 2007 09:29 GMT
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?
}
> > Hi,
> >
[quoted text clipped - 30 lines]
>
> Pete
Peter Duniho - 24 Oct 2007 19:28 GMT
> 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