|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
ThreadPool.QueueUserWorkItemHi,
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. JT wrote:
Show quote > Hi, It's not clear, since you provided no code, what the Start method passed > > 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. 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 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? } Show quote "Peter Duniho" wrote: > JT wrote: > > 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 > JT wrote:
> Thanks Peter. I've posted some code below but from what I understand I will That depends on what you do in the handler. You are right, the handler > 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? 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 |
|||||||||||||||||||||||