Replace DefaultExecuteResultHandler with AtomicExecuteResultHandler #110
Conversation
vorburger
force-pushed
the
issue-108_concurrency
branch
from
9f45b64
to
cc9d4be
Compare
vorburger
changed the title
This includes the following noteworth changes: * vorburger/ch.vorburger.exec#110 * vorburger/ch.vorburger.exec#112 * vorburger/ch.vorburger.exec#115
This includes the following noteworth changes: * vorburger/ch.vorburger.exec#110 * vorburger/ch.vorburger.exec#112 * vorburger/ch.vorburger.exec#115
This includes the following noteworth changes: * vorburger/ch.vorburger.exec#110 * vorburger/ch.vorburger.exec#112 * vorburger/ch.vorburger.exec#115
This includes the following noteworth changes: * vorburger/ch.vorburger.exec#110 * vorburger/ch.vorburger.exec#112 * vorburger/ch.vorburger.exec#115
| final long until = System.currentTimeMillis() + timeoutInMS; | ||
| while (holder.get() == null && System.currentTimeMillis() < until) { | ||
| Thread.sleep(SLEEP_TIME_MS); | ||
| } |
There was a problem hiding this comment.
this is a pretty minor nit, but for elapsed time it's safer to use System.nanoTime since currentTimeMillis is not monotone, and can flop around based on NTP.
There was a problem hiding this comment.
Great catch! Thanks a lot for this feedback. This seemed easy enough to just quickly fix - I have raised #118 for it.
|
|
||
| @Override | ||
| public void onProcessComplete(int exitValue) { | ||
| Holder witness = holder.compareAndExchange(null, new Holder(exitValue)); |
There was a problem hiding this comment.
This is slightly inconvenient for us–we're still on JDK8 (likely for the next year) so using AtomicReference#compareAndExchange (introduced in JDK9) means that we can't use ch.vorburger.exec anymore w/o forking it. We've already forked mariadb4j for JDK8 support so it's not hugely inconvenient, but I figured it's worth mentioning.
As an aside, do you prefer to use AtomicReference over VarHandle because it has a simpler API?
| * | ||
| * @see <a href="https://github.com/vorburger/ch.vorburger.exec/issues/108">Issue #108</a> | ||
| */ | ||
| public class AtomicExecuteResultHandler implements ExecuteResultHandler { |
There was a problem hiding this comment.
perhaps this is a naive question–this seems a bit like a CompletableFuture. could we simplify this by using a CompletableFuture directly?
There was a problem hiding this comment.
I vaguely see what you mean, but not entirely. That would (just) be "nicer design" but not per-se "more (concurrency) safe", is that what you mean? I am open to a PR Contrib for it, but personally not motivated enough to spend more time to change this.
There was a problem hiding this comment.
Yeah, I think the main improvement would be a more precise waitFor method. I'm not sure how much that matters, but it could speed things up slightly. I'll take a stab at it if I get some free time
see #108
@mosesn (from #103) and @cardamon (from #96) and @duttonw FYI and hope you agree this makes sense?
Do raise follow-up PRs if you can see how to make it even better!