January 1999
- From DevMud: Database module Greg Connor
- From DevMud: Database module Mik Clarke
- From DevMud: Database module Greg Connor
- From DevMud: Database module J C Lawrence
- From DevMud: Database module Greg Connor
- ADMIN: Resends and possible duplicates J C Lawrence
- Info about different skill systems Emil Eifrem
- Info about different skill systems Nathan F Yospe
- Info about different skill systems Ben Greear
- Info about different skill systems Emil Eifrem
- Info about different skill systems Ben Greear
- Info about different skill systems Emil Eifrem
- Info about different skill systems Nathan F Yospe
- Info about different skill systems Travis S. Casey
- Info about different skill systems Mik Clarke
- New features for ScryMUD (Player-run Shops) Ben Greear
- [OT Humor] Mudder's Rhapsody Jon A. Lambert
- [OT Humor] Mudder's Rhapsody Caliban Tiresias Darklock
- [OT Humor] Mudder's Rhapsody The Wildman
- Guild/skill/spell relation (or "webs") Petri Virkkula
- Guild/skill/spell relation (or "webs") David Bennett
- mobile movement Matthew Mihaly
- mobile movement Adam Wiggins
- mobile movement Koster, Raph
- mobile movement Caliban Tiresias Darklock
- mobile movement David Bennett
- mobile movement Kylotan
- mobile movement quzah [softhome]
- mobile movement Ling
- mobile movement J C Lawrence
- mobile movement Oliver Jowett
- mobile movement Oliver Jowett
- mobile movement Caliban Tiresias Darklock
- mobile movement Richard Woolcock
- mobile movement J C Lawrence
- mobile movement Ling
- mobile movement Marc Hernandez
- mobile movement J C Lawrence
- mobile movement Ling
- mobile movement Holly Sommer
- mobile movement Caliban Tiresias Darklock
- mobile movement Koster, Raph
- mobile movement Chris Gray
- Intelligent WebGlimpse archive searching at Kanga.Nu (was J C Lawrence
- [RRE]MediaMOO annual birthday symposia: 1/20 Bruce Mitchener, Jr.
- [RRE]MediaMOO annual birthday symposia: 1/20 Koster, Raph
- OT: Mike Sellers needs some help load testing J C Lawrence
- Keegan's MUD Tree J C Lawrence
- Intelligent WebGlimpse archive searching at Kanga.Nu Marian Griffith
- Intelligent WebGlimpse archive searching at Kanga.Nu Caliban Tiresias Darklock
- Intelligent WebGlimpse archive searching at Kanga.Nu Dominic J. Eidson
- Intelligent WebGlimpse archive searching at Kanga.Nu J C Lawrence
- Intelligent WebGlimpse archive searching at Kanga.Nu Marian Griffith
- GRASS GIS Web Site Elis Pomales
- Thoughts Caliban Tiresias Darklock
- mobile movement (the fault of tracking) quzah [softhome]
- ADMIN Name server problems and upes J C Lawrence
- Adjective Server Christopher Allen
- Reputations, More Mazes Eli Stevens {KiZurich}
- Reputations, More Mazes J C Lawrence
- Reputations, More Mazes Eli Stevens {KiZurich}
- Mules (was something different) Marian Griffith
- Mules (was something different) J C Lawrence
- Mules (was something different) Hans-Henrik Staerfeldt
- Levels versus Skills Marian Griffith
- Levels versus Skills Caliban Tiresias Darklock
- Levels versus Skills J C Lawrence
- Levels versus Skills quzah [softhome]
- Levels versus Skills Vladimir Prelovac
- Levels versus Skills quzah [softhome]
- Levels versus Skills J C Lawrence
- Levels versus Skills Petri Virkkula
- Levels versus Skills J C Lawrence
- Levels versus Skills Caliban Tiresias Darklock
- From Devmud: Database module, draft 3 Greg Connor
- Matrix Game Ling
- Graphic design doc Thinus Barnard
- Graphic design doc Chris Gray
- ADMIN: List server and Kanga.Nu host changes J C Lawrence
- ADMIN: List server and Kanga.Nu host changes Koster, Raph
- Sockets and fibers Caliban Tiresias Darklock
- Sockets and fibers Adam J. Thornton
- Sockets and fibers Caliban Tiresias Darklock
-----Original Message-----
From: Adam J. Thornton <adam@phoenix.Princeton.EDU>
To: mud-dev@kanga.nu <mud-dev@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@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 -ÊBAL::3146=- - Sockets and fibers J C Lawrence
- Sockets and fibers Jon A. Lambert
- Sockets and fibers Adam J. Thornton
- Sockets and fibers Dr. Cat
- Sockets and fibers Caliban Tiresias Darklock
- Sockets and fibers Jo Dillon
- [DevMUD] From Devmud: Database module, draft 3 Greg Connor
- META: list "peerage" Koster, Raph
- META: list "peerage" John Bertoglio
- META: list "peerage" diablo@best.com
- META: list "peerage" Andy Cink
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Quzah [softhome]
- META: list "peerage" Michael.Willey@abnamro.com
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Holly Sommer
- META: list "peerage" Travis S. Casey
- META: list "peerage" Andy Cink
- META: list "peerage" Quzah [softhome]
- META: list "peerage" Matthew D. Fuller
- META: list "peerage" Laurel Fan
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" David Bennett
- META: list "peerage" Bruce Mitchener, Jr.
- META: list "peerage" diablo@best.com
- META: list "peerage" Matthew D. Fuller
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Brandon A Downey
- META: list "peerage" Travis Casey
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Dominic J. Eidson
- META: List "peerage" Marian Griffith
- META: List "peerage" Caliban Tiresias Darklock
- META: list "peerage" Ola Fosheim Grøstad
- META: list "peerage" Sayeed
- Mugu Chris Gray
- META: List peerage and behaviour J C Lawrence
- META: list "peerage" Chris Gray
- ADMIN: We're working again. J C Lawrence
- Java I/O and threads. Elis Pomales
- Java I/O and threads. Jo Dillon
- Java I/O and threads. cynbe@muq.org
- Java I/O and threads. Jo Dillon
- Java I/O and threads. Elis Pomales
- Reset Death Wes Connell
- Reset Death Quzah [softhome]
- Reset Death Wes Connell
- Reset Death Mik Clarke
- Reset Death Andrew C.M. McClintock
- Reset Death Mik Clarke
- PvP and mob capacities (was "List Peerage") Caliban Tiresias Darklock
- combat diablo@best.com
- META: list "peerage" Darrin Hyrup
- META: list "peerage" J C Lawrence
- Telmaron and Mud servers was: META: list "peerage" Elis Pomales
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Ben Greear
- Who is? (was about level vs skills) Marian Griffith
- Who is? (was about level vs skills) Caliban Tiresias Darklock
- exploration points diablo@best.com
- [MUD-Dev] Juha Lindfors
- Stock Mud Demographics ##Make Nylander
- ADMIN: Off-topic and the ever present reminders on quoting. J C Lawrence
- Mud reviewing Andy Cink
- Mud reviewing Caliban Tiresias Darklock
- Mud reviewing diablo@best.com
- Mud reviewing Andru Luvisi
- Mud reviewing diablo@best.com
- Mud reviewing J C Lawrence
- Mud reviewing Dan Shiovitz
- Mud reviewing diablo@best.com
- Mud reviewing Caliban Tiresias Darklock
- Mud reviewing diablo@best.com
- Mud reviewing Richard Woolcock
- Mud reviewing David Bennett
- Mud reviewing Caliban Tiresias Darklock
- MUD Admin skills Hal Black
- Subdue Holly Sommer
- processors diablo@best.com
- processors John Bertoglio
- processors Wes Connell
- processors Laurel Fan
- processors Mik Clarke
- processors J C Lawrence
- processors diablo@best.com
- processors Quzah [softhome]
- processors Mik Clarke
- processors J C Lawrence
- processors Marc Hernandez
- processors Adam Wiggins
- processors Greg Underwood
- processors Adam Wiggins
- processors Chris Gray
- processors gunderwood@donet.com
- processors Jon A. Lambert
- processors Greg Underwood
- processors Petri Virkkula
- quests involving players diablo@best.com
- quests involving players Darren Henderson
- quests involving players Caliban Tiresias Darklock
- quests involving players Richard Woolcock