Github user ahgittin commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/816#discussion_r141614008
--- Diff:
core/src/main/java/org/apache/brooklyn/util/core/task/BasicExecutionContext.java
---
@@ -100,6 +123,121 @@ public ExecutionManager getExecutionManager() {
@Override
public Set<Task<?>> getTasks() { return
executionManager.getTasksWithAllTags(tags); }
+ @Override
+ public <T> T get(TaskAdaptable<T> task) {
+ final TaskInternal<T> t = (TaskInternal<T>) task.asTask();
+
+ if (t.isQueuedOrSubmitted()) {
+ if (t.isDone()) {
+ return t.getUnchecked();
+ } else {
+ throw new ImmediateUnsupportedException("Task is in
progress and incomplete: "+t);
+ }
+ }
+
+ ContextSwitchingInfo<T> switchContextWrapper =
getContextSwitchingTask(t, Collections.emptyList(), false);
+ if (switchContextWrapper!=null) {
+ return
switchContextWrapper.context.get(switchContextWrapper.wrapperTask);
+ }
+
+ try {
+ return runInSameThread(t, new Callable<Maybe<T>>() {
--- End diff --
This is a replacement for `submit(task).get()` -- not just `submit(task)`
followed by a lock being released. As such I think the risk of deadlock can
only go down as the job will hold the callers locks as opposed to the
submitting thread holding them while blocking on this thread, no? A change in
the other direction could introduce deadlocks so we'd have to be careful going
the other way, make sure the submitter releases locks before blocking, but
think we're fine here.
---
