[MUD-Dev] Re: MUD Development Digest

[Alex Oren]

On Wed, 8 Apr 1998 19:09:52 PST8PDT, J C Lawrence wrote:

} NT (IIRC, no source data) has a concept of "fibres" which are very
} light weight user-space threads (don't know how scheduling is handled,
} but its not classic kernel style).  NT's normal threading model is a
} fairly standard kernel threads model (much heavier weight) where
} threads compete for the process'es time-slices (IIRC).  

Fibers were introduced in NT 4.  Here's some info:

--- begin doc quote ---

A fiber is a lightweight thread that an application must manually schedule.
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.

>From a system standpoint, a fiber assumes the identity of the thread that
created it. For example, if a fiber accesses thread local storage (TLS), it is
accessing the thread local storage of the thread that created it. In addition,
if a fiber calls the ExitThread function, the thread that created it exits.
However, a fiber does not have all the same state information associated with
it as that associated with a thread. The only state information maintained for
a fiber is its stack, a subset of its registers, and the fiber data provided
during fiber creation. The saved registers are the set of registers typically
preserved across a function call.

Fibers are not preemptively scheduled. You schedule a fiber by switching to it
from another fiber. The system still schedules threads to run. When a thread
running fibers is preempted, its currently running fiber is preempted. The
fiber resumes when its thread resumes running.

--- end doc quote ---

I don't any advantage in using fibers instead of threads in a MUD server.

--
Have fun,
Alex.