Reputation: 2121
I don't want to file an issue, as I'm not at all sure (and if it is, it's a really minor flaw), but is this Javadoc comment in Futures.transform(...) with an explicit ExecutorService parameter in the signature correct?
For heavier transformations, this choice carries some caveats: First, the thread that the transformation runs in depends on whether the input Future is done at the time transform is called. In particular, if called late, transform will perform the transformation in the thread that called transform. Second, transformations may run in an internal thread of the system responsible for the input Future, such as an RPC network thread. Finally, during the execution of a sameThreadExecutor transformation, all other registered but unexecuted listeners are prevented from running, even if those listeners are to run in other executors.
I would assume it's always executed in a thread which "belongs" to the provided ExecutorService
. But it is stated in both transform-methods which require an explicit third ExecutorService instance, so I assume I'm wrong.
Upvotes: 1
Views: 313
Reputation: 198033
In both cases where it requires a third ExecutorService instance, it's discussed in the paragraph that discusses whether or not you should switch to the overload that defaults to sameThreadExecutor
. The "this choice" phrasing just about convinces me that this is discussing the case when you pass it Executors.sameThreadExecutor
.
Upvotes: 4