RxJava on JDK 21's virtual threads

[abersnaze]

I'm exploring implementing a new branch of RxJava, where the internals are rewritten to leverage JDK 21's virtual threads. I hope this will significantly simplify Rx's internal implementation and debuggability while maintaining the same interface as 3.x.

This issue is to discuss the idea positively to address architectural problems with compatibility and performance.

I haven't yet set a time frame for when or if this will be completed. I will only submit this with the community's approval. If a community of developers likes this idea and runs with it faster than I keep up, I'm also okay with stepping aside.

@akarnokd et al., Before we discuss the merits or implementation of the idea, are there any additional ground rules for this discussion?

[akarnokd]

are there any additional ground rules for this discussion?

None I can think of right now.

[Sm0keySa1m0n]

What would you envision reactive programming's new role to be with the introduction of virtual threads? I can imagine virtual threads and structured concurrency would replace most non-stream based reactive usage (e.g. Single and Mono); but for streams of data I suppose reactive streams are still useful, albeit processing of individual stream elements could again be offloaded to virtual threads and structured concurrency.

[abersnaze]

Much of the internals are devoted to non-blocking pressure. I was specifically thinking about the drainLoop

I think the debugging stack traces and internals would be much simpler virtual blocking queue were used.