[MUD-Dev] Re: TECH: Distributed Muds

[Bruce]

asnellin at san.rr.com wrote:
> On Sat, 12 May 2001, Bruce wrote:

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

... snipped ...

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

Grab a book on POSIX threads, or some similarly good reference.  You
can play various games to mitigate troubles resulting from the stack
size (like specifying your own stacks, setting stack size, etc).

But, really, see the MUD-Dev archive for other, IMHO better, threading
models.  Thread-per-connection really isn't that great for a number of
reasons, most of which have been discussed in the past, even the
relatively near past (2 weeks ago?).

  - Bruce

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