On Fri, Nov 21, 2008 at 09:27, Paul Brannan <pbrannan / atdesk.com> wrote:
> On Fri, Nov 21, 2008 at 05:45:23PM +0900, Urabe Shyouhei wrote:
>> Ko1 explained me about this.  According to him, 1.8 threads are slower
>> because context switching on 1.8 needs a lot of memory copies.  1.8
>
> 1.8 threads do a lot of memory copies on context switch, but they are
> not all necessary.  The stack can be switched on some platforms using
> swapcontext.
>
> (but this isn't a trivial change either; the implementation of threads
> on 1.8 is complex and is tightly coupled to eval.c)

From what I understand, the NeverBlock [0] has used 1.9 Fibers to
achieve its goal. I believe they have ported it to 1.8 in some effect
[1] (most likely not at the Thread level but at the C ext. level with
stack allocation and swapping). Anyone know what the caveats are with
their implementation?

I would imagine it would be possible to have a C extension provide
working fibers as long as the GC was made aware of the stack so it
could scan the stacks appropriately. Threads would also probably have
to be modified a bit to work in concert (jumping back to the proper
fiber before making the context switch I would guess).

Brian.

[0] http://www.espace.com.eg/neverblock

[1] http://www.espace.com.eg/neverblock/blog/2008/09/04/neverblock-instant-scaling-for-your-rails-apps/