I'm not aware what they used before, but why pthreads? Isn't this perfect opportunity to try to develop something better, introduce new concepts (async, coroutines or some kind of userspace deterministic job management)? Not sure if backward compatibility is best way to go here, but maybe i'm just talking gibberish
I agree that raw threads are a terrible abstraction for application programmers to manipulate directly. Actors and CSP are much better concurrency models for application developers to use.
However, if you're going to do low-level OS and language runtime programming for multi-core computers, threads are a good abstraction on top of which you'd implement CSP or Actors. Also, there's tons of legacy software that uses lots of raw pthread calls, so to have any kind of adoption of a UNIX-like OS, you're going to have to support pthreads.
Putting aside the need to port code from elsewhere and not exist in your own private universe, this is a bit like saying remove the filesystem APIs because we have a database. Both are valid things to keep around. Given the choice there are still lots of instances where you would pick the former.
I'm aware of this and it's rational choice, but whata opportunity. They (just maybe) could also add compatibility layer on top of something else, like other projects do, but nvm.
Comments
I'm not aware what they used before, but why pthreads? Isn't this perfect opportunity to try to develop something better, introduce new concepts (async, coroutines or some kind of userspace deterministic job management)? Not sure if backward compatibility is best way to go here, but maybe i'm just talking gibberish
They used cthreads before.
I agree that raw threads are a terrible abstraction for application programmers to manipulate directly. Actors and CSP are much better concurrency models for application developers to use.
However, if you're going to do low-level OS and language runtime programming for multi-core computers, threads are a good abstraction on top of which you'd implement CSP or Actors. Also, there's tons of legacy software that uses lots of raw pthread calls, so to have any kind of adoption of a UNIX-like OS, you're going to have to support pthreads.
Putting aside the need to port code from elsewhere and not exist in your own private universe, this is a bit like saying remove the filesystem APIs because we have a database. Both are valid things to keep around. Given the choice there are still lots of instances where you would pick the former.
I'm aware of this and it's rational choice, but whata opportunity. They (just maybe) could also add compatibility layer on top of something else, like other projects do, but nvm.