All the usual stuff is still available, so depending on what you need you could just use a `Queue` as the communication bus between several fibers. Anything wrapped in a Mutex would also work, since waiting for the lock is handled by the FiberScheduler.
That said I imagine that for most Ruby applications the real answer would be "you don't and you don't really need to". The most obvious killer applications for Fibers and FiberSchedulers seem to be web servers (most requests spend quite some time waiting for DB/API calls) and IO-intensive background jobs (also here, the majority of the time is spent waiting for some external server to respond). Fibers all get multiplexed on the same operating system thread anyway, so you don't really increase parallelism by communicating between individual fibers.
If you really wish to use multiple parallel threads in Ruby, Ractors are the way to go or otherwise C extensions that drop the GIL. That is outside the scope of Fibers though.
That said I imagine that for most Ruby applications the real answer would be "you don't and you don't really need to". The most obvious killer applications for Fibers and FiberSchedulers seem to be web servers (most requests spend quite some time waiting for DB/API calls) and IO-intensive background jobs (also here, the majority of the time is spent waiting for some external server to respond). Fibers all get multiplexed on the same operating system thread anyway, so you don't really increase parallelism by communicating between individual fibers.
If you really wish to use multiple parallel threads in Ruby, Ractors are the way to go or otherwise C extensions that drop the GIL. That is outside the scope of Fibers though.