Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@Blocking #101

Open
hutchig opened this issue Jun 4, 2020 · 0 comments
Open

@Blocking #101

hutchig opened this issue Jun 4, 2020 · 0 comments
Labels
enhancement New feature or request
Milestone

Comments

@hutchig
Copy link
Member

hutchig commented Jun 4, 2020

@Blocking

This issue is to converge/resolve/document how to markup methods being run completely asynchronously, and thus potentially concurrently, in seperate threads and the semantics of what these mean. I have called it @Blocking because that is the name of the annotation Quarkus/SmallRye use for this (see the 1.4 April release).

We need a place to converge/standardise about aspects such as if users expect to get the same hardware thread if ordered execution is selected etc. For example they might expect not to need locking but also can't use ThreadLocal etc. (At least as standardized in MP as some runtimes, I am thinking about OpenLiberty, we will want to be able to shrink threadpools and so threads here today may be gone tomorrow.

Please don't pollute this issue with general non-technical discussion (e.g. about using github too 'early').

@hutchig hutchig added the enhancement New feature or request label Jun 4, 2020
@Emily-Jiang Emily-Jiang added this to the Future milestone Jul 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants