Re: Fiber thing?

[Sean Middleditch <elanthis@...>]

Fibers are fairly simple.  Basically, when a single OS thread is
running, you have your registers and code stack.  Say you are in the
middle of some Lua code, which was called from a C function, which was
invoked from some other Lua code.  If the Lua interpreter decides to
switch Lua threads, it can't be easily done, because of that C function
on the call stack.

With fibers, you'd do something like this.  Each function stack you got
into (Lua call stack), you'd get to a point where you decide to swap
fibers.  Basically, this code would copy the stack and registers to a
buffer (or, depending on implementation and needed stack size, leave it
where it is), push the intruction pointer, swap the stack pointer, and
pop the instruction pointer, pull out the new buffer's stack/data, and
pop the instruction pointer again.  You'll have just popped the
instruction pointer from the new stack, and thus your new thread will be
running.

I'm not too great at explaining these, especially given that I've never
used them myself and thus don't have any code to use as an example.  You
need to look at from the CPU's perspective, tho, not the OS - the OS has
nothing to do with the fibers.

On Sat, 2002-06-08 at 04:21, Alex Bilyk wrote:
> See comments inline.
> 
> 
> ----- Original Message -----
> From: "Christopher S. Charabaruk" <ccharabaruk@meldstar.com>
> To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
> Sent: Saturday, June 08, 2002 12:23 AM
> Subject: Re: Fiber thing?
> 
> 
> > A fiber is to a thread, what a thread is to a process. I hope that helps.
> >
> 
> 
> But what facilities is it based on? Everything is a thread under OS. Some
> treads are called 'threads' just to indicate that they are subordinate to
> the 'main' ('process') thread. As to the context switching mechanics, the
> difference between the two is not so greate. If this is so, I would think
> that behind each 'fibber' there is an OS thread. Is this correct?
> 
> longmp/setjmp base systems on Win32 will result in copying of at least  128
> bites per pair. In oder to implement the C-based mocrothreads it would take
> at least two pairs or 256 bytes to copy per switch. I can think of tons of
> applications where 10x of that will be no problem. But... if one had to
> handle, say, 5000 of such OS or LJ/SJ based fibers,  I would be really(!)
> concerned about perfromnace. I tend to side with those believing that
> switching a pointer is all it has to take conseptually to implement
> microtreads in LUA.
> 
> I might not know what I am talking about as I have 0 (that is *zero*)
> experience with fibers or LJ/SJ though. Current response from people about
> Lua5 coroutines sounds good to me (where can I get this 'work' version?). At
> least I can see how I could try to use then for my application.
> 
> I tend to side with those that accept certain restrctions imposed on
> preempting inside C functions isomg LUA microthreads. The body of any C
> function registered with LUA is not a part of LUA VM. Whoever wants to
> preempt them from LUA should get familliar with OS-based threadding
> facilities specifically designed for handling such cases.
> 
> As the last thing I would like to know what to get Lua5 work version!?
> Thank you,
> 
> AB
> 
> > Alex Bilyk wrote:
> >
> > >What is this *fiber* thing? I would appreciate if you elaborated a bit on
> > >this or provded some pointers I could follow.
> > >Thank you,
> > >AB
> > >
> > >----- Original Message -----
> > >From: "Curt Carpenter" <curtc@microsoft.com>
> > >To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
> > >Sent: Friday, June 07, 2002 11:23 AM
> > >Subject: RE: cooperative multitasking
> > >
> > >
> > >
> > >
> > >>As an platform-specific detail, let me just add that on Win32 I have had
> > >>very successful results using a fiber for each Lua thread, and switching
> > >>the fiber instead of using Lua's coroutines. The major advantage is that
> > >>switching a fiber is just a handful of machine instructions. It
> > >>basically just swaps out registers. Using Lua's coroutines requires that
> > >>you unwind the Lua call stack, wind it back up when you continue. The
> > >>only downside is that you need stack space for each thread (but you
> > >>configure that to just what you need). I have run over 1000 fibers/Lua
> > >>threads without any problems. Plus, with fibers you can switch out while
> > >>in the middle of a registered C function. Anyway, it's not a
> > >>general-purpose Lua thing, so it's not for everyone, but I thought some
> > >>people might be interested in that approach if it's a possibility for
> > >>them.
> > >>
> > >>-----Original Message-----
> > >>From: Luiz Henrique de Figueiredo [mailto:lhf@tecgraf.puc-rio.br]
> > >>Sent: Friday, June 07, 2002 9:56 AM
> > >>To: Multiple recipients of list
> > >>Subject: Re: cooperative multitasking
> > >>
> > >>
> > >>
> > >>
> > >>>Long-running threads with lots of processing would be sprinkled with
> > >>>yield calls, no?
> > >>>
> > >>>
> > >>Yes, that's why it's called cooperative multitasking.
> > >>
> > >>
> > >>
> > >>>Or I suppose one could use the line-hook, although that would be quite
> > >>>slow.
> > >>>
> > >>>
> > >>Or the call hook.
> > >>
> > >>Anyway, cooperative multitasking is provide now in the core of Lua. If
> > >>your platform allows multithreading then you can add that too. An
> > >>example is given in LuaThreads:
> > >>http://www.tecgraf.puc-rio.br/~diego/luathreads/
> > >>--lhf
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Chris 'coldacid' Charabaruk <ccharabaruk [at] meldstar [dot] com>
> > Meldstar Studios <http://www.meldstar.com/> - Creation, cubed.
> >
> >
> >
>