Process forking on Windows

[Andrew Robert]

Hi everyone,


I have a python program that will need to interact with an MQSeries
trigger monitor.

It does this fine but it hogs the trigger monitor while it executes.

I'd like to fork the program off and terminate the parent process so
that the trigger monitor frees up.


Does anyone how this can be accomplished on a Windows platform?

I've looked at doing this via the subprocess module but this doesn't
look like the correct approach.

Any help you can provide would be greatly appreciated.

Thanks

 

[bruno at modulix]

Hi everyone,


I have a python program that will need to interact with an MQSeries
trigger monitor.

It does this fine but it hogs the trigger monitor while it executes.

I'd like to fork the program off and terminate the parent process so
that the trigger monitor frees up.

<just-asking>
Is this really the solution ?

Does anyone how this can be accomplished on a Windows platform?

AFAIK, there's no fork in Windows - you might want to give a try with
CreateProcess.
http://www.byte.com/art/9410/sec14/art3.htm
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/UCMGch01.asp

HTH

 

[Gary Herron]

Hi everyone,


I have a python program that will need to interact with an MQSeries
trigger monitor.

It does this fine but it hogs the trigger monitor while it executes.

I'd like to fork the program off and terminate the parent process so
that the trigger monitor frees up.


Does anyone how this can be accomplished on a Windows platform?

I've looked at doing this via the subprocess module but this doesn't
look like the correct approach.

Any help you can provide would be greatly appreciated.

Thanks

The "subprocess" module gives a (mostly) platform independent way for
one process to start another. It provides a number of bells and
whistles, and is the latest module on a long history of older modules to
provide such functionality.

Gary Herron

 

[Andrew Robert]

<just-asking>
Is this really the solution ?


AFAIK, there's no fork in Windows - you might want to give a try with
CreateProcess.
http://www.byte.com/art/9410/sec14/art3.htm
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/UCMGch01.asp

HTH

Unfortunately there is a real need for this.

The MQSeries trigger monitor is single threaded.

Because of this, my program would absorb it until it completes.

The way to get around this would be to fork off and terminate the parent.

Unfortunately, Windows appears to be somewhat stubborn about it.

Creating a subprocess does not alleviate the need to get the originating
process out of the trigger monitor.

 

[Gary Herron]

bruno at modulix wrote:




Unfortunately there is a real need for this.

The MQSeries trigger monitor is single threaded.

Because of this, my program would absorb it until it completes.

The way to get around this would be to fork off and terminate the parent.

Unfortunately, Windows appears to be somewhat stubborn about it.

Creating a subprocess does not alleviate the need to get the originating
process out of the trigger monitor.

The windows CreateProcess call has many of the same semantics as the
Unix fork, i.e., a new process is created sharing all the resources of
the original process. The "subprocess" modules uses CreateProcess, but
if that does not give you sufficient control over the process creation,
you can call CreateProcess directly via the "win32process" module in the
win32all package.

However, I still don't understand *what* the "MQSeries trigger monitor"
is or *how* it would create the need for such a solution.

Gary Herron

 

[Andrew Robert]

Andrew Robert wrote:

The windows CreateProcess call has many of the same semantics as the
Unix fork, i.e., a new process is created sharing all the resources of
the original process. The "subprocess" modules uses CreateProcess, but
if that does not give you sufficient control over the process creation,
you can call CreateProcess directly via the "win32process" module in the
win32all package.

However, I still don't understand *what* the "MQSeries trigger monitor"
is or *how* it would create the need for such a solution.

Gary Herron

MQSeries is a rather interesting piece of middle-ware offered by IBM
that allows you to link disparate hosts/applications together via XML
messaging and application specific queues.

In the broadest sense, think of MQSeries like a large switchboard
connecting everything together.

Message queues can be programmed to do something via a mq application
process such as a rule to take action when first, 5th, etc message arrives.

The state of queues and their linked processes are controlled by the
trigger monitor.

The trigger monitor can only deal with one running process at a time.

In this situation, it is possible for a process(my python program) to
monopolize and block other processes from being triggered.

Ideally, this needs to be avoided through the use of a fork.

If you are interested, you can get all kinds of Websphere MQSeries and
Websphere Message Broker information at
http://www-306.ibm.com/software/integration/wmq/library/


On a side note, I use the pymqi module to make calls to MQSeries.

 

[bruno at modulix]

Unfortunately there is a real need for this.
The MQSeries trigger monitor is single threaded.

Because of this, my program would absorb it until it completes.
The way to get around this would be to fork off and terminate the parent.
Unfortunately, Windows appears to be somewhat stubborn about it.
Creating a subprocess does not alleviate the need to get the originating
process out of the trigger monitor.

Have you *really* read the material pointed by the above links ?

 

[bruno at modulix]

MQSeries is a rather interesting piece of middle-ware offered by IBM
that allows you to link disparate hosts/applications together via XML
messaging and application specific queues.

In the broadest sense, think of MQSeries like a large switchboard
connecting everything together.

Message queues can be programmed to do something via a mq application
process such as a rule to take action when first, 5th, etc message arrives.

The state of queues and their linked processes are controlled by the
trigger monitor.

The trigger monitor can only deal with one running process at a time.

In this situation, it is possible for a process(my python program) to
monopolize and block other processes from being triggered.

Ideally, this needs to be avoided through the use of a fork.

Since there's no fork() on Windows, how do other programs working with
MQSeries deal with this situation ? How does it comes that your program
'monopolize' the monitor, while other don't ?

 

[Tim N. van der Leeuw]

bruno at modulix wrote: [...]

<just-asking>
Is this really the solution ?
</just-asking>

[...]


Unfortunately there is a real need for this.

The MQSeries trigger monitor is single threaded.

Because of this, my program would absorb it until it completes.

The way to get around this would be to fork off and terminate the parent.

Unfortunately, Windows appears to be somewhat stubborn about it.

Creating a subprocess does not alleviate the need to get the originating
process out of the trigger monitor.

I have my doubts that this will solve the problem.

You have a process that communicates with another, single-threaded,
piece of software. If you fork of a sub-process, then you have another
process communicating (and hogging up) this single-threaded piece of
software.

Well, if your original program is long-running, your sub-process is
short-running, and you cannot 'disconnect' from the MQ Monitor other
than by terminating a process, yes then I can see how using a
subprocess could solve your problem... But I don't know why the
SubProcess module doesn't do what you want.

Cheers,

--Tim

 

[Benji York]

In this situation, it is possible for a process(my python program) to
monopolize and block other processes from being triggered.

Ideally, this needs to be avoided through the use of a fork.

Another option would be to write the incoming messages to your own queue
(an on-disk directory perhaps) and have the triggered program return
after doing that. Then you can have a separate, long-running program
process the messages.