[Home] [Groups] - Message: [Prev in Group] [Next in Group]
24624: Re: [MUD-Dev] Socket Code
[Full Header] [Plain Text]
From: "Blane Bramble" <bbramble@montavista.co.uk>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 13 Aug 2002 13:38:52 +0100
References: [1]
Organization: Kanga.Nu
From: "Stephen Miller" <stephen@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@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev