[MUD-Dev] Re: Sockets and fibers

[Caliban Tiresias Darklock]

-----Original Message-----
From: Adam J. Thornton <adam at phoenix.Princeton.EDU>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Wednesday, January 20, 1999 10:02 AM
Subject: [MUD-Dev] Re: Sockets and fibers


>On Wed, Jan 20, 1999 at 09:11:06AM -0800, Caliban Tiresias Darklock wrote:
>> Has anyone here looked at the possibilities of spawning a single thread
>> which handles sockets and then using Microsoft's "fibers" to handle
>> individual sockets? How much of the one-thread-per-socket problem would
be
>> solved by this? With the speed of modern computers, what are the real
>> problems with just serialising the socket handling -- one thread with all
>> the sockets, servicing each socket in turn for some small time slice?
>>
>> Yes, I know, writing MUD servers under Windows is Bad. Granted. All the
>> same. ;)
>
>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? I mean, I could handle 16
14.4 modems under DOS on a 286 running ZModem downloads on arbitrary files,
so theoretically I could do about the same with 40 56K lines on a P166, but
hopefully the Pentium is even faster than that and could handle a lot more.
Furthermore, downloads are protracted operations, which I don't really need
to do, so I should be able to handle even more folks. Plus I'm a better
programmer now than I was in '91. ;)

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.

Hopefully this will mean that given the two hardware-specific files, anyone
who knows the target architecture can rewrite them so they work under that
machine, and we can drop them in and recompile. In practice, there will
probably be other problems that need to be addressed, and it's likely that
some sort of conflict will arise between two O/S platforms eventually. I
anticipate the major platforms will be Linux, Solaris, BSDi, and Windows;
starting under Windows will probably leave me room to spare on the others.
(With Windows in the mix, of course, the code must be 64-bit safe just in
case of an Alpha market.)

>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."

This doesn't bother me overly, since (given the details I've omitted) it's a
simple matter of never ignoring a return value and never discarding a
pointer without freeing its associated data, both of which I am rather anal
about. But what really disturbs me is the idea that fibers are supposed to
be used by a single-threaded application, evidently making it an
almost-multithreaded application. I don't get that at all. I may be looking
at an ad-hoc solution to a very specific issue which I don't have. According
to the above, you would theoretically be safe if you had multiple threads
but only one of them had fibers and it was never terminated until the end of
the program anyway.

| Caliban Tiresias Darklock            caliban at darklock.com
| Darklock Communications          http://www.darklock.com/
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=-