undefined | Better HN

0 pointskaba02y ago0 comments

Wtf, where on Earth do you put blocking code then? Firing off some long-running task in a background thread through executors is bog-standard usecase.

0 comments

riku_iki2y ago

discussion was about specific context: avoiding overhead from spawning millions of threads, in this case you shouldn't have any blocking code at all, all API should utilize epoll underneath or something similar.

kaba0OP2y ago

And where do you handle callbacks?

riku_iki2y ago

there are tons of variations, depending on your logic and API. The closest to virtual threads is ForkJoinPool and RecursiveTask, where you can have code like regular blocking code:

var f = async_api_returns_future();

...

var res = f.join();

but join() won't block OS/JVM thread, but make it to perform other tasks in the queue.

Or you can design API which will receive executorService as params, and run callback there, e.g.:

async_call(Callable callback, ExecutorService threadPool);

1 more reply

j / k navigate · click thread line to collapse

0 comments

riku_iki2y ago

kaba0OP2y ago

And where do you handle callbacks?

riku_iki2y ago

there are tons of variations, depending on your logic and API. The closest to virtual threads is ForkJoinPool and RecursiveTask, where you can have code like regular blocking code:

var f = async_api_returns_future();

...

var res = f.join();

but join() won't block OS/JVM thread, but make it to perform other tasks in the queue.

Or you can design API which will receive executorService as params, and run callback there, e.g.:

async_call(Callable callback, ExecutorService threadPool);

1 more reply

j / k navigate · click thread line to collapse