Inquiry on thread semantics

[fzakaria]

Hello,

I had a question regarding the project.
The problem I've encountered with Vert.x and using CompletableFutures is you have to be very explicit about which ThreadPool (EventLoop vs. WorkerThread) to run your chained tasks.

Consider the following:

public CompletableFuture<Void> write(RequestContext context) {
    Assertions.assertOnEventLoop();
    return new VertxCompletableFuture(vertx).supplyBlockingAsync( () -> {
          Assertions.assertOnWorkerThread();
          //do some work
    }).thenRun( () -> {
          //This assertion can fail!
         Assertions.assertOnWorkerThread(); 
         //do some work
     });
}

CompletableFuture may schedule the thenRun on the client thread (EventLoop) if it noticed it has finished already (https://www.nurkiewicz.com/2015/11/which-thread-executes.html)

The README claims that this sort of problem should be taken care of but I don't see how in the code.
Looking for some more explanation.

The answer above is simple -- make to execute thenRunBlocking again, however its been a GOTCHA several times for me.

[cescoffier]

We don't support supplyAsync. It's a static method with a clear semantic about the fork join thread pool (in java 8). It returns a new completable future (not a vert.x one).