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

[Gary Herron]

Re: Process forking on Windows

Andrew Robert wrote:
[color=blue]
>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
>
>[/color]
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

[bruno at modulix]

Re: Process forking on Windows

Andrew Robert wrote:[color=blue]
> 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.[/color]

<just-asking>
Is this really the solution ?
</just-asking>
[color=blue]
>
> Does anyone how this can be accomplished on a Windows platform?[/color]

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/de...l/UCMGch01.asp

HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Andrew Robert]

Re: Process forking on Windows

bruno at modulix wrote:[color=blue]
> Andrew Robert wrote:[color=green]
>> 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.[/color]
>
> <just-asking>
> Is this really the solution ?
> </just-asking>
>[color=green]
>> Does anyone how this can be accomplished on a Windows platform?[/color]
>
> 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/de...l/UCMGch01.asp
>
> HTH[/color]


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]

Re: Process forking on Windows

Andrew Robert wrote:
[color=blue]
>bruno at modulix wrote:
>
>[color=green]
>>Andrew Robert wrote:
>>
>>[color=darkred]
>>>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.
>>>
>>>[/color]
>><just-asking>
>>Is this really the solution ?
>></just-asking>
>>
>>
>>[color=darkred]
>>>Does anyone how this can be accomplished on a Windows platform?
>>>
>>>[/color]
>>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/de...l/UCMGch01.asp
>>
>>HTH
>>
>>[/color]
>
>
>Unfortunatel y 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.
>
>Unfortunatel y, 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.
>
>[/color]

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 "win32proce ss" 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]

Re: Process forking on Windows - or what is MQSeries

Gary Herron wrote:[color=blue]
> Andrew Robert wrote:
>[/color]
<snip>
[color=blue]
>
> 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 "win32proce ss" 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
>
>[/color]
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]

Re: Process forking on Windows

Andrew Robert wrote:[color=blue]
> bruno at modulix wrote:
>[color=green]
>>Andrew Robert wrote:
>>[color=darkred]
>>>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.[/color]
>>
>><just-asking>
>>Is this really the solution ?
>></just-asking>
>>[color=darkred]
>>>Does anyone how this can be accomplished on a Windows platform?[/color]
>>
>>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/de...l/UCMGch01.asp
>>[/color]
> 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.
>[/color]

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



--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[bruno at modulix]

Re: Process forking on Windows - or what is MQSeries

Andrew Robert wrote:[color=blue]
> Gary Herron wrote:
>[color=green]
>>Andrew Robert wrote:
>>[/color]
>
> <snip>
>[color=green]
>>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 "win32proce ss" 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
>>
>>[/color]
>
> 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.[/color]

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 ?


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Tim N. van der Leeuw]

Re: Process forking on Windows


Andrew Robert wrote:[color=blue]
> bruno at modulix wrote:[/color]
[...][color=blue][color=green]
> >
> > <just-asking>
> > Is this really the solution ?
> > </just-asking>
> >[/color][/color]
[...][color=blue]
>
>
> 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.[/color]

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]

Re: Process forking on Windows - or what is MQSeries

Andrew Robert wrote:[color=blue]
> 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.[/color]

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.
--
Benji York