------ art_21571_9508357.1187783411147 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/22/07, Daniel Berger <djberg96 / gmail.com> wrote: > > Here's how fibers are described by MSDN: > > 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'm not sure this is germane because I don't know if the Ruby Fiber class maps to the Microsoft object you describe, Dan. But MS added what they call "fibers" to the Win32 system about 10 years ago in order to facilitate porting of POSIX-thread libraries. At that time, you recall, thread architecture still wasn't a settled issue. MS's threads were (and are) analogous to Solaris lightweight processes. But Solaris and many other Posix thread libraries at the time had pure userland threads that were not kernel-scheduled entities. Since you could easily have tens of thousands of Solaris threads and only one or two hundred Windows threads in a single process, Microsoft felt competed against and they introduced this Fiber thing, which is somewhere in the middle between a full LWP and a full userland thread. From day 1, MS recommended that Fibers not be used in any new code. ------ art_21571_9508357.1187783411147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/22/07, <b class mail_sendername">Daniel Berger</b> <<a href ailto:djberg96 / gmail.com">djberg96 / gmail.com</a>> wrote:<div><span class mail_quote"></span><blockquote class mail_quote" style order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Here's how fibers are described by MSDN:<br><br>A fiber is a unit of execution that must be manually scheduled by the<br>application. Fibers run in the context of the threads that schedule<br>them. Each thread can schedule multiple fibers. In general, fibers do <br>not provide advantages over a well-designed multithreaded application.<br>However, using fibers can make it easier to port applications that were<br>designed to schedule their own threads.</blockquote><div><br><br>I'm not sure this is germane because I don't know if the Ruby Fiber class maps to the Microsoft object you describe, Dan. But MS added what they call "fibers" to the Win32 system about 10 years ago in order to facilitate porting of POSIX-thread libraries. <br><br>At that time, you recall, thread architecture still wasn't a settled issue. MS's threads were (and are) analogous to Solaris lightweight processes. But Solaris and many other Posix thread libraries at the time had pure userland threads that were not kernel-scheduled entities. Since you could easily have tens of thousands of Solaris threads and only one or two hundred Windows threads in a single process, Microsoft felt competed against and they introduced this Fiber thing, which is somewhere in the middle between a full LWP and a full userland thread. <br><br>From day 1, MS recommended that Fibers not be used in any new code.<br></div><br></div> ------ art_21571_9508357.1187783411147--