On Mon, Oct 21, 2024 at 5:43 PM Mark Thomas <ma...@apache.org> wrote: > > Spinning off this specific topic. > > On 08/10/2024 13:25, Rémy Maucherat wrote: > > On Tue, Oct 8, 2024 at 7:51 AM Christopher Schultz > > <ch...@christopherschultz.net> wrote: > > >> In the pub track at the end of the day, I proposed bringing back the BIO > >> connector with Virtual Threads as the magic which makes everything work. > >> markt is convinced the idea has merit and on initial hand-waving > >> conversation, he thinks that maybe just maybe Tomcat 12 could dump both > >> NIO and NIO2 connectors, the Poller and other complexities. Servlet > >> async and Websocket both seem to have solutions based upon BIO and VT. > >> The question is whether or not VT will reach the level of maturity > >> required for Tomcat and downstream users to rely on it for production > >> workloads. Our initial sense is that yes, the promises of VT will be > >> realized in the timeframe during which Tomcat 12 will become stable. > > > > This still looks difficult to me, as native code support cannot be > > fixed. Of course polling is complex but it works. I don't expect this > > to change, so VT would remain a niche use. Is there anything new that > > changes this ? > > The only thing that has changed is more thinking. > > Back when I was trying to implement WebSocket on top of the Servlet API, > the reason I kept hitting deadlocks was that I was only using container > threads allocated in response to poller events. Even when we relaxed the > rule to one thread per request/response to one read thread and one write > thread per request/response deadlocks were still possible. > > I haven't fully thought this through but I got as far as thinking it > could be worth experimenting with was something along the following lines: > > - for blocking IO use virtual threads the same way we currently use > platform threads > > - for a non-blocking read/write start a virtual thread to do the > read/write that executes the completion handler (or Future) code when > the read/write completes or fails > > - we'd need a simple state machine for Servlet non-blocking IO to ensure > isReady() returned the correct value and that there were no more than > one non-blocking read and one non-blocking write in progress at the > same time > > I haven't thought very much about WebSocket or h2 but I think there is > the potential to make both of the simpler to implement. > > The plan didn't get much further than start a branch for the > refactoring, see how it goes and if it looks like it might work as for > more feedback at that point. > > What was the concern around native code? That it pins the platform > thread? That should be OK if we are only using OpenSSL for operations we > don't expect to block like encryption.
Yes, native code needs a native thread to be run. Although it does not block, I would expect the sheer amount of calls to have an impact. Rémy > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
