Re: [cu-dev] BALLOT to allow opting in to virtual threads (vote by Tues

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

+1 (non-binding)

I think it's good to have a standard way to provide a hint for using virtual threads, although there's no way to enforce that the implementation will actually respect that hint. Without that, I believe that multiple implementations would provide support for virtual threads, each with different means to turn it on. It's better to align on the same standard hint.

Ondro

On Tue, Aug 29, 2023 at 4:59 PM Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

In order to make progress on Jakarta Concurrency 3.1, we need to resolve the question of whether or not the specification will include a way for users to provide a hint requesting that if possible managed executors and managed thread factories should run on or create virtual threads rather than platform threads. Issue 268 https://github.com/jakartaee/concurrency/issues/268 has some background discussion.

 

A vote of +1 is a vote for adding a hint for requesting virtual threads rather than platform threads.

 

A vote of 0 is a vote to abstain and is not counted for or against the proposal.

 

A vote of -1 is a vote for leaving the Concurrency specification without any way for users to indicate their preference for virtual vs platform threads.

 

This vote will be counted by simple majority of +1 or -1 votes from Jakarta Concurrency specification committers as listed in https://projects.eclipse.org/projects/ee4j.cu/who . 

 

Non-committers are encouraged to vote as a measure of community sentiment.

 

This BALLOT will run until Tuesday 2023-09-12 10:00AM CDT or when all committers have voted, whichever comes first.

 

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev