- July 28th meeting minutes: accepted - Peter: Proposal to solve synchronization issue raised in the last meeting - wait() / waitAny() is only for getting notified about some transition event - new dedicated function to fetch the history of state changes - Roger: If waitAny() then returns for one job, what about the transitions of other jobs ? - Roger: Proposal: Return job(s) that changed state since a given point in time - Dan: In general, three approaches for synchronization capability - 1) State change notification without history keeping in-between the wait() / waitAny() calls -> sounds useless - Waiting for a state to happen (similar to old wait() if we include reaping) - State change event callback functionality in the API - Roger/Dan: There is no real use case for long-ago historical state changes, let's just care about last transition and current state - Agreement that event notification (as precondition for callbacks) is not supported by majority of DRM systems -> wait() solution must rely on some kind of pull model - To be useful, wait() functions have to wait on transitions, since current state querying is covered in another part of the API - Wait() functions should save from fetching job states in a loop - Dan: Difference between waiting for any job state change (information dropping ok) vs. waiting for state change of one particular job - Roger: Concern about waitAny() not returning the current state of a job which transitioned between waitAny() invocations. - Need to go back to original use cases: - Waiting for job start - Writing qstat with DRMAA - Writing qmon with DRMAA - Waiting for job end (DRMAA1) - -> Discussion on mailing list - Roger: Current waitAny() specification allows caller to indicate the jobStates of interest - Need to discuss if/how this effects a subsequent call requesting different jobStates - Is waitAny concerned with the most recent transition for a job after the previous waitAny(), or the previous waitAny in which the jobState was returned.