Andrew Robert wrote: > Gary Herron wrote: > >>Andrew Robert wrote: >> > > <snip> > >>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.
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 '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list