> I'd actually love to see such a paper. Plan 9 threading is more like coroutines, but it is certainly possible to run multi-core/multi-process code.
Rob Pike was on of the main developers behind plan 9 and Go and involved in concurrent programming research focusing on CSP.
Multi-processing was a main focus of plan 9's design and it works well as procs are cheap to spawn on plan 9. Procs are also the smallest unit of execution on plan 9, threads are just light weight procs with a shared heap to pass pointers around. Thread stacks can also be shared as well by being allocated on the heap via fork(2) RFMEM flag (its all done with malloc in the background).
The issue with vanilla (aka labs or legacy ) plan 9 is there is a hard coded limit of 2k procs statically allocated at boot. This was a pragmatic design decision. The unfortunate side effect is vanilla plan 9 falls over under any sort of work load requiring spawning lots of procs like handling web requests. This is actively being worked on by 9front developers so sites hosted on 9front should hold up better (patches welcome :-).
> That said, I can't say I've seen anyone try to write anything that scales like nginx on Plan 9.
Because you really don't need those big web serving monoliths on plan 9. You wire things up using rc scripts and programs like execfs (implements cgi) plus httpd/tcp80 or another web serving listener and sandbox code using namespaces. Plan 9 is more true to unix philosophy and more unix than unix. (edit: execfs is experimental but available on shuthub.us along with other webstuff like tcp80)