[MUD-Dev] Socket Code

Blane Bramble bbramble at montavista.co.uk
Tue Aug 13 13:38:52 CEST 2002


From: "Stephen Miller" <stephen at pagemiller.com>

> So the basic gist of this system would be to have a thread for
> each connection which has a blocking select.  Each time the select
> receives input on its socket, it grabs the input and if it should
> have a line, it will lock (through semaphores or mutexes) the
> respective shared memory player queue and push the new line onto
> the back of the queue.  Then it unlocks and blocks again for more
> input.

I haven't looked at this for a bit - but I believe one of the issues
with doing this with Linux is, each thread gets it's own stack space
assigned.  This is a fairly sizeable chunk of VM (even if it is not
being used) - 2Mb springs to mind, but I might be wrong. Create a
few hundred threads, and you have a large chunk of VM allocated, and
I believe the system may start to grind. Of course this may have
been fixed by now...

Consider possibly pooling connections, and using a thread for each
pool of players. That way you get to play with select() and threads!

> The advantages of the second way seem to be...

>   a) don't have to copy fd set all the time on each socket

I just build up a new fdset with the sockets I know I am interested
in.

>   b) don't have to call select each pass

With a timeout, this isn't a significant problem - if there is alot
of input, your overhead to the select() call is probably low
compared to processing all the input. If there is not much (or any)
input, a sensible timeout will mean you are not eating up major
processing time in a select() loop.

>   c) don't have to match up file descriptors with classes.

Hardly a problem surely?

>   d) I get to play with threads (you cannot overlook this one! :p)

Nothing stopping you using threads for other purposes anyway! Or
even using a mix of select/threads or poll/threads.

> In any case, I also heard that this would scale better and be
> "faster" with say...120 sockets, which doesn't really seem all
> that important but better design for the long haul is something I
> believe in.

By my understanding threads do not scale at all well beyond a few
hundred - but this was a discussion I had quite a while ago, so
maybe they've moved on.

Blane.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list