[MUD-Dev] Re: TECH: Distributed Muds

[asnellin at san.rr.com]

On Wed, 9 May 2001, Jon Lambert wrote:
> asnellin at san.rr.com
  
>> On the issue of threading vs polling for network connections, what
>> are the practical limits to the number of threads in a system? 
>> Disregarding, for a moment, restrictions on data sharing and time
>> associated with waiting for locks (which is admittedly a lot to
>> disregard) what kind of performance hits come up when you have
>> hundreds of threads in a process?

> Practical thread limits are very much dependent on hardware, OS and
> design.  If you write your thread code well, it's likely you'll hit
> the practical sockets limit before you hit the practical threads
> limit.  There is no reason to assume one thread per socket.  In some
> instances, I have two threads servicing one socket, or 1 thread
> serving 5 sockets.  That happens with notification mechanisms.  With
> threads the biggest bugaboo (outside of data sharing and locking
> which are mostly bigger bugaboos IMO) is heap contention.  Heap
> contention causes frequent context shifts.  You get into heap
> contention when you allocate many resources and free those
> resources.  Which is another reason why threads need to have well
> defined tasks much like one designs a function to be cohesive.

Ah, thank you for the insight. I went and did some research on heap
contention, and I see what you're talking about. I found a few
solutions, including the ones you mentioned on local storage and
allocation caches, and other ideas like restructuring objects to limit
the amount of pointer references and thus the amount of alloc/dealloc
calls. I knew there had to be something along those lines I should be
watching for, thanks for pointing it out.

> Needless to say, I don't think you want to get into a design that
> repeatedly creates and destroys threads.  I try create a pool of
> threads at the start of my server app and remove them when the app
> terminates.

I'm looking at a design where each connection has a certain number of
static threads dedicated to certain common tasks (input, output,
communications, world interaction, etc.) so these would be created at
connection time. I can see, though, that a sudden spike in connections
could overload this, as could a moderate level of connection turnover
in a system that averaged many hundreds of connections at a time.

On another tack, what is the hard limit on posix threads in a system
or process? I know there is a number beyond which creations will fail,
but I don't know what it is.

-- Andrew


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