[MUD-Dev] Re: TECH: Distributed Muds

[asnellin at san.rr.com]

On Sat, 12 May 2001, Bruce wrote:
> 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. :)

Actually, it's more like a constant number of threads per connection,
likely only one or two. But that's why I'm asking these questions -- would
N*2 threads kill a system, even if intelligently managed? Even if 90% of
them were blocking at any given point in time?

Or more explicitly, is it impossible (or simply foolhardy) to attempt a
heavily multithreaded design?

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

I came across a few of these discussions when doing searches on the
topic. I didn't realize that threads had that kind of memory footprint,
though. 2M is an awful lot.


-- Andrew

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