Re: Fiber thing?

["Christopher S. Charabaruk" <ccharabaruk@...>]

From the MSDN Collection:
> A fiber is a unit of execution that must be manually scheduled by the
> application. Fibers run in the context of the threads that schedule
> them. Each thread can schedule multiple fibers. In general, fibers do
> not provide advantages over a well-designed multithreaded application.
> However, using fibers can make it easier to port applications that
> were designed to schedule their own threads.

I've never dealt with fibers, I have no clue what use they could be, at 
least for me. I've understood them to be sub-threads, though perhaps 
that's not the best way to think of them.


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.


--
Chris 'coldacid' Charabaruk <ccharabaruk [at] meldstar [dot] com>
Meldstar Studios <http://www.meldstar.com/> - Creation, cubed.