[MUD-Dev] Multi-threaded programming under Linux

[Cynbe ru Taren]

[cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray):]

| Yep!
| 
| The big problem with not using OS-level threads is that you only get
| to have one system call active at a time in your whole program. With
| OS-level threads, you can have several threads actively doing system
| calls. That lets you have threads updating your on-disk database or
| something, at the same time as other threads are doing socket calls.

Again, I don't want to suggest OS-level threads aren't a reasonable
design choice:  They are.  But, as usual, there's more than one way
to skin a cat.

select() on nonblocking sockets lets one effectively multiplex lots of
I/O: On a uniprocessor, OS threads really aren't going to improve
stuff on the net I/O front.

Blocking an entire multi-user server for disk I/O is certainly nasty:
If it gets to be a significant problem, I've been intending to switch
to a dual-process implementation, where one runs in-memory stuff and
the other handles all the "slow" system calls, mostly disk I/O: They
can communicate via a pipe or shared memory segment.  This is creeping
up on OS multithreading but still quite portable: Pipes and shared
memory are pretty stable and standard at this point, especially vs
threads.

Having the host OS automatically spreading threads across multiple CPUs 
is definitely nice if you've got 'em!  (Just building my first dual-cpu
box, to get my feet wet.)

On the other hand, my design is anyhow intended to support
WAN-distributed worlds, so for me, running enough local servers to
keep multiple CPUs busy isn't out of the question, and yields the
benefit of segmenting the state into managable-sized hunks (which
isn't a bad thing) and of giving a degree of graceful degradation: If
one server crashes, a subset of the world state goes unresponsive,
but users on the other servers can chug right along,  whereas with
the multithreads in a single server, you tend to lose the whole
shebang when something goes wrong.  Interprocess firewalls were
introduced for a reason, dispensing with them isn't a pure and
simple win. :)

 Cynbe