brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <>
Subject [GitHub] brooklyn-server issue #816: Tasks code improvements - prep for better presen...
Date Thu, 28 Sep 2017 15:00:04 GMT
Github user ahgittin commented on the issue:
    Think I've addressed everything except `getImmediately(unsubmittedTask)`.
    > My expectation for what getImmediately(task) should do is: try to evaluate the task
immediately, but if it couldn't then leave the task in a good state so if someone else does
task.get() then it will still be usable.
    I think the only way to support your expected behaviour is to run it in a separate thread.
 And this defeats the point of most uses which is to be lightweight and throw away the task
    So I think the best thing to do is clarify the semantics in javadoc that unsubmitted tasks
will be cancelled (and clean up the tests a bit -- though more would always be welcome --
and add the `isExecutingImmediately` guard you noted), with a note that callers should use
the `TaskFactory` pattern if that behaviour is not desired (because the `TaskAdaptable` will
cause it to create a new task instance).
    While a `getImmediatelyOrSubmitIfWeCant` would be nice, it is problematic.  We often won't
know if a task doesn't support immediate until we've tried running it, and it does a `wait`
or similar, and throws.  If we don't want it to throw, then we can't neatly enforce that it
doesn't block (without polling the other threads state or maybe via low level hacks).  So
I think you probably end up doing `submit(task).get(SHORT_TIMEOUT)`.
    There might be room for a `Tasks.getImmediatelyIfSafeElseSubmitAndShortWait()` utility
method that does a subset of the checks (including if it's being given a `TaskFactory`) and
tries to avoid unnecessary submits but doesn't risk cancelling an externally supplied task.
 I'll review usages and see.
    Thoughts @aledsage ?


View raw message