[MUD-Dev] Modular Design Issues RFC

[Jo Dillon]

On Friday 16 February 2001 07:33, Scion Altera expostulated:
> Thursday, February 15, 2001, 7:08:18 AM, Ryan Rhodes wrote:

>> However, for some reason my instincts tell me that commercial games
>> maintain a separate thread for each player.  This 'player' thread
>> has it's own infinite loop and from it parses the players input,
>> creates events, and executes them, thus simulating time for the
>> player.

> Not in Java on a unix machine they wouldn't.

> My current project went through a stage where I had it set up just
> like that. It was great because I could detect disconnects and block
> for I/O without any trouble... and nobody else cared if your player
> thread crashed.

> However, keep in mind that every Java thread creates a new process
> in unix. On a game with a high number of players, you would quickly
> find yourself using up thousands of PIDs. I'm no expert, so I don't
> know what effects that would have on a linux or solaris box, but I
> can't imagine it would be pretty.

A new /lightweight/ process, aka thread. BIG difference. Lightweight
processes don't have their own address space, file descriptors and so
on.  On Linux they will indeed each take up their own PID (Linux maps
threads straight to kernel entities) - on Solaris the thread library
will basically create several kernel threads and map all those
thousands of Java threads on to them (so effectively you have
half-a-dozen processes sharing the same address space, each of which
is running a bunch of userspace threads). On OSes without kernel
thread support all the threads will be running within one
process. That's not to say thousands of threads is pretty and
efficient, but I imagine a thousand shouldn't be too much bother given
the speed of modern machines.

--

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