[MUD-Dev] Re: Sockets and fibers

[Adam J. Thornton]

Whoops.  Sent this earlier from the wrong account.

On Wed, Jan 20, 1999 at 10:36:44AM -0800, Caliban Tiresias Darklock wrote:
[Adam:]
> >How would this differ from a poll-and-select() model under a Real OS?
> 
> 
> By poll-and-select I assume you mean the standard "port concentrator" type
> thing where you have a big array of sockets and just iterate through it
> looking for recv() data and sending data where necessary. This was sort of
> my final question; is that really a bad thing?

There are a couple of web server designs that do it that way; if you don't
mind doing the bookkeeping yourself, it gives quite good performance on
modern hardware.

> As far as a Real OS goes, I'm designing under Windows primarily because it's
> going to be easier to port *from* Windows later. (Lacking a user interface,
> this is a lot easier than your average Windows-to-other port.) I'm intending
> to separate all the O/S dependencies into two files; one to handle
> connections and send/recv (I always have to correct "xmit" to "send" when I
> talk about that) and one to handle access to files and resources on the
> server. Everything else will be straight C using the standard library, and
> will not interact with the user or the network in the slightest other than
> through a simple command/response API.

Well, OK, but why do Windowsisms at all?  If Windows has a POSIX.1 layer
(surely it must, musn't it?  I admit I haven't looked, but I'd assume it
would) then you can do all this with Posixy calls, and save yourself almost
all the OS-dependent bits.

> >I suppose this really turns into a request about what a fiber is.
> 
> Per MS docs: "A fiber is a lightweight thread that is manually scheduled.
> Specific fiber APIs include: ConvertThreadToFiber() CreateFiber()
> DeleteFiber() GetCurrentFiber() GetFiberData() SwitchToFiber()"
> 
> Yeah, I don't get it either. Furthermore, MS adds:
> 
> "Fibers are designed to be employed by a single-threaded application, in
> which case the leak will never occur. However, if threads with fibers are
> started and terminated repeatedly, this can cause accumulation of memory
> leaks and will eventually cause the process to run out of memory."

Er, yuck.  Assuming that Windows implements something like a nonblocking
select(), I'd think that'd be the way to go instead.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman