@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').
@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').