Torque/PBS DRMAA - drmaa_wi* POSIX equivalents I
Issue: Using drmaa_wifaborted(), drmaa_wifexited(), drmaa_wifsignaled(), etc. is tedious and error-prone. For example, it's not clear what the right order of all the calls should be and what if none of them gives a meaningful answer, i.e. the job exit status could not be determined somehow. Some one-call semantics to get job exit status should be considered. Of course, this would kill all these formal POSIX semantics of wait and wif* functions. ----------------------- I agree here that the usage is not straightforward sometimes. We wanted to follow POSIX for conformity, so many developers are expected to be already familiar with the macros semantics. This is a complex issue that requires substantial effort, so we need to mark this issue as the future versions work. -Hrabri
Issue:
Using drmaa_wifaborted(), drmaa_wifexited(), drmaa_wifsignaled(), etc. is tedious and error-prone. For example, it's not clear what the right order of all the calls should be and what if none of them gives a meaningful answer, i.e. the job exit status could not be determined somehow. Some one-call semantics to get job exit status should be considered. Of course, this would kill all these formal POSIX semantics of wait and wif* functions.
-----------------------
I agree here that the usage is not straightforward sometimes. We wanted to follow POSIX for conformity, so many developers are expected to be already familiar with the macros semantics.
This already triggered long discussions in the DRMAA group. The IDL spec looks like this: --- snip interface JobInfo { readonly attribute string jobId; readonly attribute Dictionary resourceUsage; readonly attribute boolean hasExited; readonly attribute long exitStatus; readonly attribute boolean hasSignaled; readonly attribute string terminatingSignal; readonly attribute boolean hasCoreDump; readonly attribute boolean wasAborted; }; interface Session{ ... JobInfo wait( in string jobName, in long long timeout) ... } --- snip A language mapping can represent the output informations with several functions, like today in C DRMAA, or use the result structure as result of the call, like today in Java DRMAA. Therefore, the overall language-independent issue is solved, but for the DRMAA C binding it would demand a new version of the C API specification. Therefore, I suggest to open a new tracker item for the C binding. Regards, Peter.
This is a complex issue that requires substantial effort, so we need to mark this issue as the future versions work.
-Hrabri -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
participants (2)
-
Peter Troeger -
Rajic, Hrabri