[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

19015: RE: [MUD-Dev] Re: TECH: Distributed Muds

[Full Header] [Plain Text]
From: Chris Gray <cg@ami-cg.GraySage.COM>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 26 Apr 2001 19:31:23 -0600
Organization: Kanga.Nu
> From: "Derek Snider" <derek@idirect.com>

> A blocking select would make it so your server would only be able to
> do anything when it receives a command... and would not be able to
> do any other tasks -- unless it was multi-threaded.

> You need it to be non-blocking, with a small delay in your main loop.

You don't use select() to delay for a time interval. You can use other
techniques for that (unless you have some specific reason, of
course). You use select to wait for socket activity *or* a specific
time interval. That's what it was designed for, and that works just
fine for a MUD server. I've used it in both of mine with no troubles
at all. In AmigaMUD, I don't have time "ticks", but you can schedule
activity with 1/20 second granularity, and using select() works just
fine. That way, the server is absolutely idle until either the next
scheduled event is ready, or there is some socket activity that needs
attention. Oh yes, I find I need a hundred of my fake "players" before
I notice much load at all on this 300 Mhz PII.


(On releasing the source - I find I need some cleanups, and I'm
awaiting a reply from the author of the Java client about releasing
it.)

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg@ami-cg.GraySage.COM
               http://www.GraySage.COM/cg/
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev