On 23/05/2022 20:41, Rémy Maucherat wrote:> On Mon, May 23, 2022 at 6:29 PM Mark Thomas <ma...@apache.org> wrote:

On 23/05/2022 17:27, ma...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
       new 0a94801588 Refactor to remove syncs on SocketWrapper to support Loom 
experiments
0a94801588 is described below

commit 0a9480158874ea910a4d629d24f31d69d6cc5f96
Author: Mark Thomas <ma...@apache.org>
AuthorDate: Mon May 23 17:27:24 2022 +0100

      Refactor to remove syncs on SocketWrapper to support Loom experiments

  From what has been posted on dev@, I think this should be sufficient
for folks that want to explore loom to get started. I strongly suspect
further changes will be required as those experimenting with loom expand
the range of Tomcat features they want to use. My thinking is we address
any additional refactoring as the need for it is identified.

I read the instructions for Loom and researched, and it doesn't seem
to me like a good fit for an app server, to be honest. At this point
at least. Thread locals apparently don't work as well, so there's a
large amount of the functionality that cannot be implemented (AFAIK).
 From the IO side, it would mean going (back) to java.io if we're
really serious about it, since it's the most efficient (it's basically
java.io > NIO > NIO2).

And applications and frameworks would have to be re-written to not use the non-blocking APIs in the Servlet and WebSocket specs.

I can see the potential benefits but the scale of change required to realize those benefits makes me think it is unlikely to happen any time soon. I can see a potential migration path that could work but it would take multiple major Jakarta EE releases to implement. Such a change would take a long time to agree and then even longer to implement.

Hence my current thinking. Make sufficient changes for folks to start to experiment and make any additional changes as the need (and associated benefits) are identified.

Also native code is kind of a problem it seems.

A notable issue for us given the integration with OpenSSL.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to