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.
Furthe
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 bu
Thanks Ralph.
-- Nathan
Correspondence
-
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndeb...@lanl.gov
--
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
Nathan
I have found the problem. It will take me a day to fix it - I'll let
you know when it is done.
Thanks
Ralph
At 03:05 PM 2/1/2006, you wrote:
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()
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 using
