Skip to content
This repository has been archived by the owner on Feb 8, 2024. It is now read-only.

Wrong example usage of CompletableFututure's async methods #13

Open
Bastian opened this issue May 15, 2020 · 5 comments
Open

Wrong example usage of CompletableFututure's async methods #13

Bastian opened this issue May 15, 2020 · 5 comments

Comments

@Bastian
Copy link
Member

Bastian commented May 15, 2020

We have examples like this in the docs:

server.createTextChannelBuilder()
    .setName("new-channel")
    .create()
    .thenAcceptAsync(channel -> {
        // This code is already running async, so you can safely use join() here
        Message message = channel.sendMessage("First!").join();
        message.addReaction("👍").join();
    });

thenAcceptAsync(...) and other async methods use the ForkJoinPool.commonPool() by default. This pool is bound to the nuber of cpu cores and is not meant to be used for blocking operations.

@Vampire
Copy link
Member

Vampire commented May 15, 2020

While I second using proper asynchronous programming instead of blocking on additional threads, what is it meant to be used for if not for long-running or blocking operations?
As far as I understood it, the ...Async methods are exactly for not blocking the thread the completes the future if the action is long-running or blocking, using the asynchronous strategy of the completable future which by default is the common fork join pool, yes.

@Bastian
Copy link
Member Author

Bastian commented May 15, 2020

It's meant for computational tasks, not for blocking tasks. E.g., parallel streams is a perfect example that uses the common pool, too.

@Vampire
Copy link
Member

Vampire commented May 15, 2020

What would you suggest for a blocking task instead?
I considered blocking and long running (aka computational) the same in this regard.
You let the CF do it on another thread to not block the calling thread.

@Bastian
Copy link
Member Author

Bastian commented May 15, 2020

What would you suggest for a blocking task instead?

Either use an own or Javacord's executor service or just don't block.

I considered blocking and long running (aka computational) the same in this regard.

The common pool size is limited to the core count of the machine, so there's a difference.

See https://stackoverflow.com/a/46073118

@Vampire
Copy link
Member

Vampire commented May 15, 2020

Ah, yes, makes sense of course.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants