[MUD-Dev] Re: Sockets and fibers

Jon A. Lambert jlsysinc at ix.netcom.com
Sun Jan 24 21:00:01 CET 1999


On 20 Jan 99, J C Lawrence wrote:
> 
> What does NT's implementation of fibers give you above the simple
> and fairly obvious cooperative task switching commonly used in MUD
> servers?  I have no idea.  I suspect that it mostly gives you a
> uniform (?) interface to the concept with some documented
> behaviours.
> 

Nod, fibers are almost equivalent to writing your own context switching 
system.  The advantage here is complete control over scheduling, the 
disadvantage is of course the complexity of writing your scheduler.  The 
scheduler you write might be slower or faster than using threads, depending on
the complexity of the scheduler.  The nice thing is, while threads are wholly
dependent on how your OS timeslices, prioritizes and preempts running tasks,
fibers allow your application to make decisions on when to preempt based on
anything _you_ believe is important to the application. There are a couple
advantages of fibers vs. roll-your-own.  First, there is already a documented
common API.  The actual context switch code is already written and very
granular already, saving and loading registers, etc.  Sure you could design
your own custom API that did this, although you would probably have to resort
to a few lines of assembler to match the speed of the fiber context switch.  Or
settle for the lower granularity simular to what many muds' VMs do to effect a
context switch.   Second, there are whole host of asynchronous and overlapped
file/network I/O functions that are exposed on the NT platform when you use
fibers (or threads).  So some of the advantages are very platform specific.

Good description of threads, BTW. 

--
--*     Jon A. Lambert - TychoMUD       Email:jlsysinc at .ix.netcom.com      *--
--*     Mud Server Developer's Page <http://pw1.netcom.com/~jlsysinc>      *--
--* I am the Dragon of Grindly Grund, but my lunches aren't very much fun, *--
--* For I like my damsels medium rare, And they always come out well done. *--




More information about the mud-dev-archive mailing list