I think I'm still not making myself clear. Here's the scenario I'm asking if we support (or why we don't): 1) Thread 1 does drmaa_wait("1", -1) 2) Thread 2 does drmaa_wait("1", -1) 3) Job 1 ends 4) DRMAA sends exit status and resource usage to Thread 1 5) DRMAA sends exit status and resource usage to Thread 2 6) DRMAA reaps the info for job 1 (only once) 7) Threads 1 and 2 return from drmaa_wait() calls Two threads concurrently call drmaa_wait for the same job. Both get the exit info, and DRMAA only reaps the info once. Daniel Rajic, Hrabri wrote:

Thinking about it a little further, I can see where you might have wanted the spec to say that, but I don't think it's clear. The spec says that all calls subsequent to a *successful* call get an error. In the case below, neither is successful until step three, and then it's arguable as to whether the second call is subsequent to the first call's

success or not. Regardless, my point is that we need to make it clear in the spec, whatever we decide it should say.

So, is there a reason why the spec is supposed to say that two concurrent calls can't both succeed? That sounds very limiting, and I completely fail to see the advantage. You can't tell me that it's for ease of implementation, after the weeks of work I put into implementing the PartialTimestamp class.

Memory issues for large number of submitted job situations led us to specify reaping only once semantics.

Hrabri

Daniel