dokyun

> Of course no doubt that (hopefully) C compilers used for compiling plan 9 things won't break it

You use the Plan 9 compiler to compile Plan 9 programs. Attempts at trying to get GCC to compile Plan 9 programs correctly have been mixed.

> So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't

Yeah. It's not a C99 compiler.

> Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.

Yeah. They're not C99 programs.

> Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99.

Sounds like C99's problem.

> to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must.

Architecture problem. Do your programs normally saturate a 40 gig network pipe?

> The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.

You can boot up a Plan 9 kernel and tell me if it works or not. Like, this is not a high bar, but you keep treating it like it is because it's based on the assumption that all compilers are broken with the set of all compilers being GCC.

> As long as you want to use shared memory to communicate with concurrent processes

That's something pthreads do and CSP doesn't.

> you need a memory model with compiler support. Even if you exclusively use mutexes.

If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."

It seems like the guy analyzes how Pthreads are formally defined and declares that "Threads cannot be implemented as a library". Maybe if the title was changed to "Pthreads cannot be implemented as a library" it'd be true. Pthreads are fucking abysmal.

> We explicitly do not address the less frequently used environments in which multiple concurrent threads communicate communicate primarily through message passing, such as C programs communicating only through the MPI[34] library, or Erlang[11] or Concurrent ML[28] programs.

Heh, there's your answer. CSP FTW!

> You need compiler/language support to ensure atomics are handled properly

That's an assumption that you're treating as though it somehow informs reality. I gave you an example of atomics being handled by a library, and the man page points to where in the source code it's defined.

> so you'd need to know how Plan 9's compiler/language specifies atomics.

It doesn't, as far as I can tell. Kencc is a very "dumb" compiler that does little magic nor does it extend the language beyond the standard C that the Bell Labs guys were used to. For whatever reasons, they found it expedient to write new libraries instead of changing the language itself. They did occasionally write compilers for new languages when they had wacky ideas that would be difficult to accomodate, like Newsqueak and Alef. In Alef's case they actually did accomodate some of it, which is how Plan 9 got libthread.

SSL added and removed here :-)

Antisec was right.

piece of paper