I see, thanks for the snippet. Won't the API be more robust (i.e. not leave it up to implementors' interpretation) by not exposing the state in any way other than getState()? The snippet above will still work by mutating existing state, and in addition such an API will prevent returning any other (possibly inconsistent) state.
So instead of doing: State myState = pipeline.waitUntilFinish(); State myOtherState = pipeline.getState(); // technically (myState != state) can be true Users will do: pipeline.waitUntilFinish(); State myState = pipeline.getState(); What do you think? On Thu, Dec 22, 2016 at 7:32 PM Lukasz Cwik <[email protected]> wrote: > I think cancel and waitUntilFinish return state because they are > interacting with the runner and are likely to have pipeline state > information available to them at the time when performing that operation. > > For example, waitUntilFinish(Duration) could just be a thin veneer of: > State state; > do { > state = getState(); > if (state is terminal) { > return state; > } > sleep > } while (time remaining) > return state; > > > > > On Thu, Dec 22, 2016 at 3:18 AM, Stas Levin <[email protected]> wrote: > > > Hi all, > > > > I was wondering if the current API for PipelineResult might open the door > > to inconsistencies stemming from cancel() or waitUntilFinish() returning > > one state, and getState() returning another? Are such cases legit? > > > > PipelineResult's API has a getState() method: > > > > State getState(); > > > > at the same time other methods such as cancel() and waitUntilFinish() > > return State as well: > > > > State waitUntilFinish(Duration duration); > > > > State cancel() throws IOException; > > > > Is this intentional? > > > > The alternative would be making cancel() and waitUntilFinish() return > void, > > so that the only (and thus consistent) way to obtain a PipelineResult's > > state would be via getState(). > > > > Am I missing something? > > > > Regards, > > Stas > > >
