On Sun, 06 Jan 2008 17:04:22 -0800, pbd22 <du*****@gmail. comwrote:
I have a C# program that fires an external VB6 program which writes to
a file and terminates.
It is ugly, but this is how I have to do it. I cannot change this part
of the program.
The problem I am encountering is that the former process created by
this EXE is not complete
(it runs for a few seconds) when the next one wants to start. A
classic multi-threading situation (i think).
Multi-process is not the same as multi-thread. So no, I don't think this
is a multi-thread situation.
The current code looks like this:
proc = new System.Diagnost ics.Process();
proc.EnableRais ingEvents = false;
proc.StartInfo. FileName = path2exe;
proc.StartInfo. Arguments = videoname;
proc.Start();
(and, I eventually added... proc.Kill(););
Why? Why don't you just wait for the process to complete?
A friend in another forum suggested I use Mutexes as a way of
queuing up requests - attaching to and detaching from the process as
needed.
He also suggested a timer given the longer length that the process
takes to complete.
I don't see anything that suggests that a mutex might be helpful.
If the external program were under your control, you could use a named
mutex that the program uses to synchronize itself with other instances of
the program. But you don't, so that's not relevant.
The code you posted is a little bewildering to me. You don't start your
timer, you just dispose it right away, and there's nothing in your post
that suggests you'll ever have a given thread waiting on the same mutex.
As far as how you _would_ do this...
Within the program you have that spawns these other processes, if you want
to queue the processes so that they only run one at a time, then you need
to do that yourself. You're not specific about how your program actually
decides to start one of these processes, but assuming you have some
mechanism for doing that, then you should just create a queue to hold
pending requests if there's already one active. You can subscribe to the
Process.Exited event (don't forget to set the Process.EnableR aisingEvents
property), and when the handler for that event is called, you can check
the queue and see if there's another one that needs to be started.
For example:
Queue<ProcessSt artInfo_procq = new Queue<ProcessSt artInfo>();
bool _fProcessRunnin g;
object _objLock = new object();
void QueueAProcess(s tring strExePath, string strArgs)
{
ProcessStartInf o psi = new ProcessStartInf o(strExePath, strArgs);
lock(_objLock)
{
if (_fProcessRunni ng)
{
_procq.Add(psi) ;
psi = null;
}
_fProcessRunnin g = true;
}
if (psi != null)
{
StartAProcess(p si);
}
}
void StartAProcess(P rocessStartInfo psi)
{
Process process = new Process();
process.StartIn fo = psi;
process.EnableR aisingEvents = true;
process.Exited += ProcessExitedHa ndler;
process.Start() ;
}
void ProcessExitedHa ndler(object sender, EventArgs e)
{
ProcessStartInf o psi = null;
lock (_objLock)
{
if (_procq.Count 0)
{
psi = _procq.Dequeue( );
}
else
{
_fProcessRunnin g = false;
}
}
if (psi != null)
{
StartAProcess(p si);
}
}
The code above makes no attempt to timeout the process. That would be a
completely separate design requirement, but so far you haven't provided
any suggestion as to why you might want a timer. Assuming you want the
processes to only run one at a time, the above will do that.
Pete
