Feature: support for JRuby

[roque86]

JRuby does not support forking, which is used here to spaw the rack server.

I have a draft fork where I just replaced processes for threads, and it seems to be working fine for JRuby. Is there anything specific that would prevent us from using threads for JRuby and perhaps adapt the code to check for that and decide how to boot up the rack server accordingly?

[lucastosetto]

@roque86 I don't think modifying the default behavior to use threads in MRI Ruby is the way to go in order to support JRuby. In summary, we would probably face some issues, like:

MRI Ruby: Using threads is limited by the GIL, preventing true parallelism and leading to complex concurrency issues like race conditions and deadlocks.

JRuby: Although threads can run in parallel, shared memory still poses risks of memory corruption and harder debugging, with potential for resource contention and reduced isolation compared to processes.

I believe we could choose between:

1. Support the threaded approach you suggested when using Rack in JRuby via a flag that needs to be explicitly configured by the developer.
2. Use posix_spawn in JRuby by default, as described in this article.

@arturictus I'd love to hear your thoughts on this.

[roque86]

Thanks for the feedback @lucastosetto.

Perhaps I was not clear enough with my initial comment but I was not really expecting or suggesting that the default behaviour would change to use threads instead of processes.

I was leaning towards detecting jruby and only then deciding on the use of threads. My fork was only a proof of concept that shows that switching to threads in jruby is enough to "make everything work".

You made some general comments regarding the differences between processes and threads, but I was wondering if there was something more specific to the gem.

For now, I am using a variation of my fork in a project but I could contribute to the gem if the general idea is acceptable.