[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