vigyasharma commented on PR #15428: URL: https://github.com/apache/lucene/pull/15428#issuecomment-3550884772
> Upon a deep dive into virtual threads - I have some concerns around implementing them as the default for everything as there are some issues around pinning and mmap that could affect lucene users. Yes, I was thinking about that too. It's a frustrating limitation with virtual threads; we can't always know if the underlying IO will use FFM in Lucene and are unable to use them. Thinking out loud here: a thread getting pinned means it doesn't unmount, which is the same as using a platform thread for the entire task? The only difference is that there is no "pooling" for virtual threads. You create a lot of them (one per task). This is a problem if the executor lives for long and can schedule many virtual threads that get pinned - eating up all the available platform threads. I would assume that in this case, the thread pins only until the reader is opened (which is not long)? And doesn't stay pinned until the reader is eventually closed?! Anyway, I agree that letting users pass an executor is the safer option here. This is a frequently invoked public API and we don't want to change default behavior in ways that can break for some users. Maybe we can write it such that it accepts an executor and passes it to the helper function, so that we can use it for both `open` and `openIfChanged` ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
