testsuite -- control and job_ps
Hi all! I noticed at least in 2 places (suspending and resuming a job) that the testsuite calls drmaa_control and expects drmaa_job_ps to return a new state right after that. As far as I remember, the spec says that it is only guaranteed that drmaa_control requests the state change from DRM and that it doesn't have to block until the change takes place actually. -- Piotr Domagalski
I noticed at least in 2 places (suspending and resuming a job) that the testsuite calls drmaa_control and expects drmaa_job_ps to return a new state right after that. As far as I remember, the spec says that it is only guaranteed that drmaa_control requests the state change from DRM and that it doesn't have to block until the change takes place actually.
Your are right, citing GFD.130 Section 9.8: "This method SHALL return once the action has been acknowledged by the DRM system, but MAY return before the action has been completed." I think you talk about the cases where check_job_state() is immediately called after drmaa_control() . In the SVN trunk of test_drmaa.c, I would blame everything around line 1887, 2076, and 2091. Do you have other locations in mind ? I would propose to relax 'check_job_state()' with some timeout mechanism, in order to give all DRM's enough time to perform the state change in a visible way. Regards, Peter.
On Tue, Nov 4, 2008 at 2:48 PM, Peter Tröger <peter@troeger.eu> wrote:
I think you talk about the cases where check_job_state() is immediately called after drmaa_control() . In the SVN trunk of test_drmaa.c, I would blame everything around line 1887, 2076, and 2091. Do you have other locations in mind ?
I don't think so. I didn't look through all the code, though. I just searched for drmaa_control(). -- Piotr Domagalski
Dear all, I changed the test suite accordingly, the new version is "1.7.1.". Implementations that worked with 1.7.0 have no need to be re-tested. Best regards, Peter. Peter Tröger schrieb:
I noticed at least in 2 places (suspending and resuming a job) that the testsuite calls drmaa_control and expects drmaa_job_ps to return a new state right after that. As far as I remember, the spec says that it is only guaranteed that drmaa_control requests the state change from DRM and that it doesn't have to block until the change takes place actually.
Your are right, citing GFD.130 Section 9.8:
"This method SHALL return once the action has been acknowledged by the DRM system, but MAY return before the action has been completed."
I think you talk about the cases where check_job_state() is immediately called after drmaa_control() . In the SVN trunk of test_drmaa.c, I would blame everything around line 1887, 2076, and 2091. Do you have other locations in mind ?
I would propose to relax 'check_job_state()' with some timeout mechanism, in order to give all DRM's enough time to perform the state change in a visible way.
Regards, Peter.
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
participants (2)
-
Peter Tröger -
Piotr Domagalski