[MUD-Dev] Re: TECH: Distributed Muds

[Chris Gray]

> From: J C Lawrence <claw at 2wire.com>

> I've never liked the base concept of a select() looping process that
> tried to do real work between select() calls.  It can work to be
> sure, but it has always smelled of playing with fire.

Can you mention any specific concerns? You have to do a select()
regularly in order to find out which client sockets have activity. (I
use it to know when I can *send* to them as well as receive - I mark
all of the sockets as non-blocking, but only add them to the select
write-set when they have plugged up.) If you don't use select(), then
it seems you either have to poll all of the connections, or have a
thread per connection. Neither seems terribly efficient to me. At work
we've been running 50+ threads on Linux and it works, at least until
you try to use gdb with them, but it still seems dicey to me.

> I prefer having a thread dedicated to socket IO, pulling in and
> buffering the IO as received, and then handling compleated blocks
> off to one or more queues (depends on whether you do pre-sorts) for
> the other game systems to pick up and process appropriately.  There
> are several advantages, not the least of which is that you decouple
> your command/entry model from your processing model.

That might be conceptually simpler to you, but it strikes me it adds
issues with locks and shared variables. In any case, it seems less
efficient, and this discussion has been a lot about the efficiency of
things. I'm a strong believer in keeping things simple until I really
know, based on direct evidence, that I have to go to something more
complex.

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

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