[MUD-Dev] Re: TECH: Distributed Muds

[Bruce]

asnellin at san.rr.com wrote:

> 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.

You really mean that if you have N people connected, you'd have N*M
threads running?

Just alone, the idea of thread-per-connection is seen to be fairly bad
in terms of scalability. :)

> 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.

Depending on the OS, you'll hit soft limits well before you hit hard
limits.

On Linux, the scheduler isn't happy with a couple of hundred threads
that are always ready to run.  (Plenty of discussion of that on
linux-kernel over the last couple of years, along with some work at
resolving these issues going on at

  http://lse.sourceforge.net/scheduling/

Each thread also has a stack, which I think defaults to 2M on
Linux. You can quickly blow your address space on threads on a 32 bit
machine.

Then there are the design and implementation issues, avoiding excess
context switches, lock contention, etc, regardless of platform.  The
importance of minimizing context switches and lock contention really
can't be emphasized enough.

If you are on Linux though, IBM is working on what they're calling the
"Next Generation Pthreads" library.  It is written in user-space and
will eventually be able to be a drop-in replacement for the libc
threading implementation.

  http://oss.software.ibm.com/developerworks/opensource/pthreads/

I can't speak to the soft or hard limits on threads for FreeBSD or
Solaris or Win32.

  - Bruce

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