Add VertxContextSupport#executeBlocking() #43444
Conversation
mkouba
commented
Sep 23, 2024
mkouba
commented
- to improve WS next UX; i.e to run blocking code in HttpUpgradeCheck#perform() easily
- to improve WS next UX; i.e to run blocking code in HttpUpgradeCheck#perform() easily
mkouba
force-pushed
the
ws-next-blocking-http-upgrade-check
branch
from
9b67cbd
to
d211835
Compare
| */ | ||
| public static <T> Uni<T> executeBlocking(Callable<T> callable) { | ||
| Context context = getContext(true); | ||
| return Uni.createFrom().completionStage(() -> { |
There was a problem hiding this comment.
defer might be slightly better.
@jponge wdyt?
There was a problem hiding this comment.
defer might be slightly better.
In what exactly? I mean, both suppliers are called at subscription time. And we would need to convert the io.vertx.core.Future to the Uni anyway.
There was a problem hiding this comment.
I was referring to https://javadoc.io/doc/io.smallrye.reactive/mutiny/latest/io.smallrye.mutiny/io/smallrye/mutiny/groups/UniCreate.html which avoid using completion stages and it's slightly more optimized. But, yes, then you need an emitter, so the cost would be almost equivalent.
There was a problem hiding this comment.
I was referring to https://javadoc.io/doc/io.smallrye.reactive/mutiny/latest/io.smallrye.mutiny/io/smallrye/mutiny/groups/UniCreate.html which avoid using completion stages and it's slightly more optimized.
There was a problem hiding this comment.
Yes, sorry, missed the anchor.
There was a problem hiding this comment.
Deferred with supplier is better, but a CompletionStage isn't incorrect per-se.
There was a problem hiding this comment.
Deferred with supplier is better, but a
CompletionStageisn't incorrect per-se.
Better in terms of performance, or?
Hm, but how do I create a Uni from io.vertx.core.Future without Uni.createFrom().completionStage()? That's what io.smallrye.mutiny.vertx.UniHelper.toUni(Future<T>) does by the way.
