Re: Fibers in Ruby 1.9?

On Thu, 23 Aug 2007 00:57:01 +0900, "Francis Cianfrocca" <[e-mail]> wrote:
> Wouldn't Fibers make things harder for everything but Windows? Linux has
> no equivalent construct whatsoever.

Untrue: there's GNU pth, for instance.  Fibers (or equivalent) don't
require much in the way of kernel support and can generally be done as
a user library.  All you need is the ability to save/restore the stack and
register contents, which also happens to be the minimum requirement for
implementing threads the same way that Ruby 1.8 does them (though most
user-thread implementations swap the stack pointer rather than the
entire contents of the stack...).

The problem for JRuby is that the JVM doesn't offer such a facility, so
you're faced with a choice between using native Java threads, explicitly
calling into a scheduler with a continuation, doing bytecode rewriting
in a custom classloader to simulate such a facility by using exceptions to
unwind/restore the stack, or running a stack machine/interpreter atop the
JVM whose stack you can manipulate.  None of those options is especially
lightweight except explicit continuation-passing, but then that isn't
transparent to use.

> (Of course in the later Linux kernels, the Linux threads, which
> actually are LWPs, don't have nearly as much scheduling overhead as
> they used to.)

To the extent that the Linux kernel has had any thread support at all,
kernel threads have always been ordinary processes that share an address
space and file descriptor table.

Prior to the implementation of address space sharing, the only option
was manipulating the CPU state from user-space (as done by pth and I
_think_ the first Linux pthreads implementation), which even now has
less scheduling overhead than kernel threads (although process
scheduling under Linux is unusually cheap compared to most operating
system kernels).

Anyway, fibers can be a useful thing to have as a foundation for
lightweight concurrency, even in the presence of native threads (e.g. you
can have a worker thread per CPU, each one executing fiber-based tasks
from a work pool), although there are portability trade-offs with respect
to environments like the JVM.

-mental