HI wonder if this is going to create a problem?
Tim/Brian/you io forwarding folks: This poses an interesting
question. We automatically wire up i/o forwarding in our spawn
routine. What happens when someone sets up their own i/o forwarding
callback and subsequently wires up stdio
I've coded a hacky workaround in our code to get past this. Basically,
I capture all of the state transitions and the first one fired for a job
I fire the 'init' state internally in our tool. Generally this occurs
for one of the gate transitions, G1 or something. It'll work this way.
Nathan --
Ralph and I talked about this and decided not to bring it over to the
1.0 branch -- the fix uses new functionality that exists on the trunk
and not in the 1.0 branch. The fix could be re-crafted to use
existing functionality on the 1.0 branch (we're really trying to only
put
Nathan
This should now be fixed on the trunk. Once it is checked out more
thoroughly, I'll ask that it be moved to the 1.0 branch. For now, you
might want to check out the trunk and verify it meets your needs.
Ralph
At 03:05 PM 2/1/2006, you wrote:
This was happening on Alpha 1 as well but
I've just finished some stuff - will check it into the system
(hopefully) tomorrow. I'll be able to take a look at this next week.
My guess is that the launcher isn't setting that proc state at this
time since it isn't being used by the system internally and we didn't
know anyone else was
This was happening on Alpha 1 as well but I upgraded today to Alpha 4 to
see if it's gone away - it has not.
I register a callback on a spawn() inside ORTE. That callback includes
the current state and should be called as the job goes through those states.
I am now noticing that jobs never
