Everything was clear the first time around ... and I do agree there is an opportunity for that one and similar cases could be better handled. First, let us extend the situation to more wait requests; many of them and/or of different sorts, and then let us see how to approach solving this problem. -Hrabri -----Original Message----- From: owner-drmaa-wg@ggf.org [mailto:owner-drmaa-wg@ggf.org] On Behalf Of Daniel Templeton Sent: Monday, January 24, 2005 9:53 AM Cc: DRMAA Working Group Subject: Re: [drmaa-wg] drmaa_wait() Clarification 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