James, Thanks for the great response. It's not a very expensive operation, so I won't worry about sharing an instance right now. Entering the world of .net, it's always nice to check to make a .net process still works the same way that I remember from CS classes :)
As for MT being tricky, that is an understatement. I thought I had some sort of subtle bug occurring at one point, and it was only after hours of debugging that I realized it was a .net bug (large object memory leak). Thanks, Erick ----- Original Message ----- From: "Murphy, James" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 6:36 AM Subject: Re: [DOTNET] Multiple threads and external utility > > -----Original Message----- > > From: Erick Thompson [mailto:[EMAIL PROTECTED]] > > > > I have an application that uses an external process/utility > > (pdftotext.exe) > > that is normally called from a command window. I use > > ProcessStartInfo and > > Process to manage the external utility. > > > There are multiple threads running this application. > > This statement doesn't make sense for the reasons you suspect below. Either > your application has many threads that start instances of pdftotext.exe or > you happen to know that pdftotext.exe is multithreaded. I imagine the first > case is the one you are interested in since the threads in pdftotext.exe do > not interact directly with your application's threads. You will have to go > out of your way to communicate between threads in your app and pdftotext.exe > because the memory address spaces of each process are protected from each > other. > > > > My concern is that if two thread try to use the > > application at the same time, there will be problems, as I > > don't know if the > > utility is thread safe. > > The question to ask is: "Can multiple instances of pdftotext.exe run > safely". If I had to guess I would say they can but you have to make sure > of this. Again, the threads from different instances of pdftotext.exe do > not interact like threads in a single process/AppDomain can. > > > > By using a process object, am I avoiding threading > > problems because a new process is created, so the threads > > will never cross? > > Yep. Though the notion that you are "avoiding threading problems" is a > little misleading. IMO, If you have multiple threads you will at one time > or another have threading problems. That's just the nature of MT programming > - its tricky. :) > > > If not, what is best way to make sure that only one thread at a time is > > using the external utility. > > You would have to virtualize the pdftotext.exe resource so you could > serialize your AppDomain's threads. Create a PDFToTextTool class with a > Doit() method that invokes pdftotext.exe. You can use all the FCL thread > synchronization tools to serialize threads into that method. But again you > may not care if multiple instances of pdftotext.exe can run simultaneously. > Then the question becomes a scalability one - is it really expensive to run > multiple instances of pdftotext.exe? Does my app perform better if a share > an instance etc. > > Jim > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
