views:

45

answers:

2

I have an application that processes file transfers. In some instances, I need to launch some pre/post processing executables that do stuff with the files.

So the order of events (in brief) would be like this:

  1. Worker thread is created
  2. Worker realizes it needs to launch a pre-process executable before starting the transfer Pre-process is launched, worker waits... if it waits too long, the transfer will not occur and the thread should finish gracefully
  3. File is transferred
  4. Worker realizes it needs to launch a post-process executable after the transfer is finished
  5. Post-process is launched, worker doesn't care to wait

Basically, I don't care how long the post process executable runs after the transfer has occurred. Therefore, should I anticipate any problems if I launch the process from a thread that is then returned to the pool?


//Post process

        Process process = null;
        ProcessStartInfo psi = new ProcessStartInfo(executable, args);
        psi.UseShellExecute = true;

        try
        {
            process = Process.Start(psi);
            //The pre-process simply calls Process.WaitForExit(timeout value)
            launched = true;
        }
        catch (InvalidOperationException) { }
        catch (ArgumentException) { }
        catch (System.ComponentModel.Win32Exception) { }
        catch (System.IO.FileNotFoundException) { }
+2  A: 

There is nothing wrong with that at all.

Think about it:

  • Returning a thread to the threadpool doesn't actually mean anything - the thread is still there.
  • Processes are not in any way dependent on their parent threads or processes - it's possible for a process to spawn a child process and then exit.
SLaks
I would add to this answer the recommendation of using `Task` objects (if you're on .NET 4.0). They propogate exceptions cleanly and support a unified cancellation model.
Stephen Cleary
A: 

That's very dangerous. If you use up all of your thread pool threads on long-running tasks then other things that need them will stop working. You can even dead-lock your whole application.

The rule is simple:

  • Short and fast: Thread Pool Thread
  • Long and slow: Manually created thread
Jonathan Allen
"very dangerous" - I think you're being a little too conservative. The .NET thread pool has a [default limit of 250 threads](http://msdn.microsoft.com/en-us/library/0ka9477y.aspx), which you can enlarge if necessary. Consuming one of these threads to wait on a process is unlikely to cause harm.
Tim Robinson
Wrong. He isn't waiting until the process finishes.
SLaks
I've used up the entire tread pool before. Sure it was back when the default was only 100, but it can happen at surprising times.
Jonathan Allen