September 2002
- A "dev chat" with Brad McQuaid Vincent Archer
- Article on Griefers Rayzam
- Article on Griefers Stephen Miller
- Article on Griefers Michael R. Estepp
- Serialization, dealing with changing classes. Neil Edwards
- Serialization, dealing with changing classes. Sean Kelly
- Serialization, dealing with changing classes. Ammon Lauritzen
- Serialization, dealing with changing classes. Brian Lindahl
- TECH: Serialization, dealing with changing classes. Mark Kochanowski
- Ballerium: Interesting Game John Arras
- Ballerium: Interesting Game Valerio Santinelli
- Ballerium: Interesting Game John Robert Arras
- Ballerium: Interesting Game Crosbie Fitch
- Ballerium: Interesting Game shren
- Ballerium: Interesting Game Peter Tyson
- Ballerium: Interesting Game Valerio Santinelli
- Ballerium: Interesting Game Vincent Archer
- Ballerium: Interesting Game Mark Cheverton
- Ballerium: Interesting Game huserl@yahoo.com
- Ballerium: Interesting Game Adam
- Ballerium: Interesting Game Valerio Santinelli
- Ballerium: Interesting Game Jon A. Lambert
- Much Respect to JessicaM apollyon
- Much Respect to JessicaM Michael Tresca
- Much Respect to JessicaM Sean Kelly
- Much Respect to JessicaM Dave Rickey
- Much Respect to JessicaM Matt Mihaly
- Much Respect to JessicaM Michael Tresca
- Much Respect to JessicaM apollyon
- Much Respect to JessicaM Daniel.Harman@barclayscapital.com
- Much Respect to JessicaM Sean Kelly
- Much Respect to JessicaM Michael Tresca
- Much Respect to JessicaM Paul Schwanz
- Much Respect to JessicaM Richard A. Bartle
- PK/PD (was Much Respect to JessicaM) justice@softhome.net
- MudDev - FAQ 1 Marian Griffith
- MudDev - FAQ 2 Marian Griffith
- [decentralization] Reputation device (fwd) J C Lawrence
- [decentralization] Reputation device (fwd) Daniel.Harman@barclayscapital.com
- [decentralization] Reputation device (fwd) Crosbie Fitch
- ANNOUNCE: Open Betas Daniel.Harman@barclayscapital.com
- ANNOUNCE: Open Betas Vincent Archer
- ANNOUNCE: Open Betas Richard Aihoshi aka Jonric
- ANNOUNCE: Open Betas Mordengaard
- ANNOUNCE: Open Betas Mordengaard
- Charlie Munger on the Psychology of Human Misjudgment J C Lawrence
- Charlie Munger on the Psychology of Human Misjudgment [summary of points] Sasha Hart
- Point of View Ted L. Chen
- Point of View Shane P. Lee
- Point of View Damion Schubert
- Point of View justice@softhome.net
- Point of View Shane P. Lee
- Point of View listsub@wickedgrey.com
- Point of View justice@softhome.net
- Point of View John Robert Arras
- Point of View Ted L. Chen
- Point of View Ted L. Chen
- Commercialization of virtual spaces Koster, Raph
- Commercialization of virtual spaces Jessica Mulligan
- Commercialization of virtual spaces Derek Licciardi
- Commercialization of virtual spaces Mike Shaver
- Commercialization of virtual spaces Justin Stocks
- Commercialization of virtual spaces Russ Whiteman
- Commercialization of virtual spaces Justin Stocks
- Flexible Perl MUD-like Server Project Luke Parrish
- Flexible Perl MUD-like Server Project stanza
- Flexible Perl MUD-like Server Project Joshua Judson Rosen
- Flexible Perl MUD-like Server Project Lars Duening
- MMOG growth Matt Mihaly
- MMOG growth Koster, Raph
- MMOG growth Daniel James
- UO Advanced Character Service Christopher Allen
- UO Advanced Character Service Jessica Mulligan
- UO Advanced Character Service eric
- UO Advanced Character Service Jessica Mulligan
- UO Advanced Character Service Matt Mihaly
- UO Advanced Character Service Matt Mihaly
- UO Advanced Character Service Amanda Walker
- UO Advanced Character Service Matt Mihaly
- UO Advanced Character Service amanda@alfar.com
- UO Advanced Character Service Marc Bowden
- UO Advanced Character Service Ted L. Chen
- UO Advanced Character Service Freeman, Jeff
- UO Advanced Character Service Damion Schubert
- Storytelling in MMOGs article Koster, Raph
- MUD-Dev Storytelling in MMOGs article Jessica Mulligan
- MUD-Dev Storytelling in MMOGs article Valerio Santinelli
- MUD-Dev Storytelling in MMOGs article Paul Boyle
- MUD-Dev Storytelling in MMOGs article Koster, Raph
- MUD-Dev Storytelling in MMOGs article Ted L. Chen
- MUD-Dev Storytelling in MMOGs article Poe, Lawrence
- MUD-Dev Storytelling in MMOGs article Dave Rickey
- MUD-Dev Storytelling in MMOGs article SpY
- MUD-Dev Storytelling in MMOGs article Freeman, Jeff
- MUD-Dev Storytelling in MMOGs article SpY
- MUD-Dev Storytelling in MMOGs article Derek Licciardi
- MUD-Dev Storytelling in MMOGs article Freeman, Jeff
- MUD-Dev Storytelling in MMOGs article Marc DM
- MUD-Dev Storytelling in MMOGs article Matt Mihaly
- MUD-Dev Storytelling in MMOGs article Marc DM
- MUD-Dev Storytelling in MMOGs article Matt Mihaly
- MUD-Dev Storytelling in MMOGs article holding99@mindspring.com
- MUD-Dev Storytelling in MMOGs article Sean Kelly
- MUD-Dev Storytelling in MMOGs article Marc DM
- MUD-Dev Storytelling in MMOGs article Sean Kelly
- MUD-Dev Storytelling in MMOGs article Mathieu Castelli
- MUD-Dev Storytelling in MMOGs article Matt Mihaly
- MUD-Dev Storytelling in MMOGs article Matt Owen
- MUD-Dev Storytelling in MMOGs article Damion Schubert
- Game developers gear up for cyber wars Michael Tresca
- Online Games Resource Guide Valerio Santinelli
- Critique this combat system Britt Green
- Critique this combat system Paul Schwanz
- Critique this combat system Edward Glowacki
- Critique this combat system hart.s@attbi.com
- [TECH] new linux thread library coming for libc Bruce Mitchener
Hey all,
Given how many people here seem to enjoy threads and use Linux, this
announcement should be of some interest.
This post is much longer than the quote below and is available in
its entirety from:
http://sources.redhat.com/ml/libc-alpha/2002-09/msg00350.html
Enjoy!
- Bruce
------begin quote-------
We are pleased to announce the first publically available source
release of a new POSIX thread library for Linux. As part of the
continuous effort to improve Linux's capabilities as a client,
server, and computing platform Red Hat sponsored the development of
this completely new implementation of a POSIX thread library, called
Native POSIX Thread Library, NPTL.
Unless major flaws in the design are found this code is intended to
become the standard POSIX thread library on Linux system and it will
be included in the GNU C library distribution.
The work visible here is the result of close collaboration of kernel
and runtime developers. The collaboration proceeded by developing
the kernel changes while writing the appropriate parts of the thread
library. Whenever something couldn't be implemented optimally some
interface was changed to eliminate the issue. The result is this
thread library which is, unlike previous attempts, a very thin layer
on top of the kernel. This helps to achieve a maximum of
performance for a minimal price.
A white paper (still in its draft stage, though) describing the
design is available at
http://people.redhat.com/drepper/nptl-design.pdf
It provides a larger number of details on the design and insight
into the design process. At this point we want to repeat only a few
important points:
- - the new library is based on an 1-on-1 model. Earlier design
documents stated that an M-on-N implementation was necessary to
support a scalable thread library. This was especially true for
the IA-32 and x86-64 platforms since the ABI with respect to threads
forces the use of segment registers and the only way to use those
registers was with the Local Descriptor Table (LDT) data structure
of the processor.
The kernel limitations the earlier designs were based on have been
eliminated as part of this project, opening the road to a 1-on-1
implementation which has many advantages such as
+ less complex implementation;
+ avoidance of two-level scheduling, enabling the kernel to make all
scheduling decisions;
+ direct interaction between kernel and user-level code (e.g., when
delivering signals);
+ and more and more.
It is not generally accepted that a 1-on-1 model is superior but our
tests showed the viability of this approach and by comparing it with
the overhead added by existing M-on-N implementations we became
convinced that 1-on-1 is the right approach.
Initial confirmations were test runs with huge numbers of threads.
Even on IA-32 with its limited address space and memory handling
running 100,000 concurrent threads was no problem at all, creating
and destroying the threads did not take more than two seconds. This
all was made possible by the kernel work performed as part of this
project.
The only limiting factors on the number of threads today are
resource availability (RAM and processor resources) and architecture
limitations. Since every thread needs at least a stack and data
structures describing the thread the number is capped. On 64-bit
machines the architecture does not add any limitations anymore (at
least for the moment) and with enough resources the number of
threads can be grown arbitrarily.
This does not mean that using hundreds of thousands of threads is a
desirable design for the majority of applications. At least not
unless the number of processors matches the number of threads. But
it is important to note that the design on the library does not have
a fixed limit.
The kernel work to optimize for a high thread count is still
ongoing. Some places in which the kernel iterates over process and
threads remain and other places need to be cleaned up. But it has
already been shown that given sufficient resources and a reasonable
architecture an order of magnitude more threads can be created than
in our tests on IA-32.
- - The futex system call is used extensively in all synchronization
primitives and other places which need some kind of
synchronization. The futex mechanism is generic enough to support
the standard POSIX synchronization mechanisms with very little
effort.
The fact that this is possible is also essential for the selection
of the 1-on-1 model since only with the kernel seeing all the
waiters and knowing that they are blocked for synchronization
purposes will allow the scheduler to make decisions as good as a
thread library would be able to in an M-on-N model implementation.
Futexes also allow the implementation of inter-process
synchronization primitives, a sorely missed feature in the old
LinuxThreads implementation (Hi jbj!).
- - Substantial effort went into making the thread creation and
destruction as fast as possible. Extensions to the clone(2) system
call were introduced to eliminate the need for a helper thread in
either creation or destruction. The exit process in the kernel was
optimized (previously not a high priority). The library itself
optimizes the memory allocation so that in many cases the creation
of a new thread can be achieved with one single system call.
On an old IA-32 dual 450MHz PII Xeon system 100,000 threads can be
created and destroyed in 2.3 secs (with up to 50 threads running at
any one time).
- - Programs indirectly linked against the thread library had problems
with the old implementation because of the way symbols are looked
up. This should not be a problem anymore.
The thread library is designed to be binary compatible with the old
LinuxThreads implementation. This compatibility obviously has some
limitations. In places where the LinuxThreads implementation diverged
from the POSIX standard incompatibilities exist. Users of the old
library have been warned from day one that this day will come and code
which added work-arounds for the POSIX non-compliance better be
prepared to remove that code. The visible changes of the library
include:
- - The signal handling changes from per-thread signal handling to the
POSIX process signal handling. This change will require changes in
programs which exploit the non-conformance of the old implementation.
One consequence of this is that SIGSTOP works on the process. Job
control
in the shell and stopping the whole process in a debugger work now.
- - getpid() now returns the same value in all threads
- - the exec functions are implemented correctly: the exec'ed process gets
the PID of the process. The parent of the multi-threaded application
is only notified when the exec'ed process terminates.
- - thread handlers registered with pthread_atfork are not anymore run
if vfork is used. This isn't required by the standard (which does
not define vfork) and all which is allowed in the child is calling
exit() or an exec function. A user of vfork better knows what s/he
does.
- - libpthread should now be much more resistant to linking problems: even
if the application doesn't list libpthread as a direct dependency
functions which are extended by libpthread should work correctly.
- - no manager thread
- - inter-process mutex, read-write lock, conditional variable, and barrier
implementations are available
- - the pthread_kill_other_threads_np function is not available. It was
needed to work around the broken signal handling. If somebody shows
some existing code which makes legitimate use of this function we
might add it back.
- - requires a kernel with the threading capabilities of Linux 2.5.36.
------end quote--------- - Zhe4 shi4 shen2me zhan4? Richard A. Bartle
- Grouping in MMP Games Dave Rickey
- Grouping in MMP Games Clay
- Grouping in MMP Games Amanda Walker
- Grouping in MMP Games Alex Kay
- Player Created Content - The Holy Grail? Matthew Dobervich
- Player Created Content - The Holy Grail? Matt Mihaly
- Player Created Content - The Holy Grail? Sulka Haro
- Player Created Content - The Holy Grail? Matt Mihaly
- Player Created Content - The Holy Grail? Michael Tresca
- Emoticons: When was the "big bang?" Randolf Richardson
- Emoticons: When was the "big bang?" Darren Henderson
- Emoticons: When was the "big bang?" Elia Morling
- Massive Online Gaming magazine Dr. Cat
- Massive Online Gaming magazine Matt Mihaly
- Massive Online Gaming magazine Dave Rickey
- Massive Online Gaming magazine Matthew Dobervich
- Massive Online Gaming magazine Dr. Cat
- Massive Online Gaming magazine Mark Cheverton
- Massive Online Gaming magazine Zach Collins {Siege}
- Massive Online Gaming magazine Dr. Cat
- Massive Online Gaming magazine shren
- Massive Online Gaming magazine Peter Tyson
- Understanding Simulation (was: Point of View) Ted L. Chen
- Understanding Simulation (was: Point of View) John Robert Arras
- Understanding Simulation (was: Point of View) Ted L. Chen
- Understanding Simulation (was: Point of View) John Robert Arras
- Understanding Simulation (was: Point of View) Derek Licciardi
- Understanding Simulation (was: Point of View) Matthew Dobervich
- Understanding Simulation (was: Point of View) Daniel.Harman@barclayscapital.com
- Understanding Simulation (was: Point of View) Travis Nixon
- Understanding Simulation (was: Point of View) Ted L. Chen
- Understanding Simulation (was: Point of View) Sasha Hart
- Understanding Simulation (was: Point of View) Ted L. Chen
- Understanding Simulation (was: Point of View) hart.s@attbi.com
- Understanding Simulation (was: Point of View) Kwon J. Ekstrom
- MUD-Dev Storytelling in MMOGs article Clay
- Diamond Age (ex story telling in MMORPG) Mathieu Castelli
- visualization toosl for text mud builders... (aka automapper) fred@clift.org
- Understanding Simulation hart.s@attbi.com
- Understanding Simulation Damion Schubert
- Understanding Simulation Michael R. Estepp
- Understanding Simulation Ron Gabbard
- Understanding Simulation shren
- Understanding Simulation Sasha Hart
- Understanding Simulation shren
- Understanding Simulation Peter Harkins
- Understanding Simulation shren
- Future of MMOGs Valerio Santinelli
- Future of MMOGs Shane P. Lee
- Future of MMOGs Eric Lee {GAMES}
- Future of MMOGs Crosbie Fitch
- Future of MMOGs Koster, Raph
- Future of MMOGs Mike Shaver
- Future of MMOGs Crosbie Fitch
- Future of MMOGs Joe Andrieu
- Future of MMOGs Crosbie Fitch
- Future of MMOGs Jeremy Noetzelman
- Future of MMOGs Sean Kelly
- Future of MMOGs Dave Trump
- Future of MMOGs Matt Mihaly
- future of MMOGs Adam
- Future of MMOGs Brack, J. Allen
- Future of MMOGs Matt Mihaly
- Future of MMOGs Matt Chatterley
- Future of MMOGs Daniel.Harman@barclayscapital.com
- Future of MMOGs Damion Schubert
- Future of MMOGs Derek Licciardi
- Future of MMOGs Jon A. Lambert
- Future of MMOGs Valerio Santinelli
- Future of MMOGs Travis Cannell
- Future of MMOGs Dr. Cat
- Future of MMOGs Crosbie Fitch
- Future of MMOGs Koster, Raph
- Future of MMOGs Crosbie Fitch
- Future of MMOGs Adam
- Future of MMOGs Amanda Walker