6 ms·

Pthreads as a case study of good API design

28 points by ekiru 16y ago

synacksynack 16y ago
While pthreads is indeed a great, simple, and easy to use API, I find it bizarre that it is without a portable timed join. It's functionality that I expected to be in a threading API, and even though it's not too difficult to work around it, it's tarnished my views of it.
- nitrogen 16y ago
  Would you care to elaborate on what you mean by "portable timed join?" A join with a timeout? If that's the case, I'm guessing you work around it by using some other synchronization method that does support timeouts.
  - synacksynack 16y ago
    Yeah, I mean a join with a timeout, and it is indeed not too much of a hassle to work around, but it's more the principle of not having an innate timed join in POSIX Threads. The Open Group published their rationale for not including a timed version of join, stating, "the working group ultimately rejected [adding a timeout to] pthread_join() since both that interface and a timed variant of that interface are non-minimal and may be implemented as a function. See below for a library implementation of pthread_join()." http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap02.html#tag_03_02_08_21 http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap0...
    - lelele 16y ago
      Well, it seems a reasonable choice, doesn't it? They provide you with building blocks to get what you want.
c00p3r 16y ago
...and bad implementation, so bad, that all modern web servers and even modern browsers were switched back to asynchronous processes and non-blocking IO. ^_^
- unshift 16y ago
  bad implementation? asynchronous IO is more efficient than threading simply because it eliminates overhead. i don't think anything was "switched back to" async IO as if threading was supposed to solve some sort of problem with it.
  - echaozh 16y ago
    People can actually switch back to "green threads" if pthread implementation is not satisfiable. However, green thread implementations like Erlang are even less popular (by my guess).

28 points by ekiru 16y ago

While pthreads is indeed a great, simple, and easy to use API, I find it bizarre that it is without a portable timed join. It's functionality that I expected to be in a threading API, and even though it's not too difficult to work around it, it's tarnished my views of it.

nitrogen 16y ago
Would you care to elaborate on what you mean by "portable timed join?" A join with a timeout? If that's the case, I'm guessing you work around it by using some other synchronization method that does support timeouts.
- synacksynack 16y ago
  Yeah, I mean a join with a timeout, and it is indeed not too much of a hassle to work around, but it's more the principle of not having an innate timed join in POSIX Threads. The Open Group published their rationale for not including a timed version of join, stating, "the working group ultimately rejected [adding a timeout to] pthread_join() since both that interface and a timed variant of that interface are non-minimal and may be implemented as a function. See below for a library implementation of pthread_join()." http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap02.html#tag_03_02_08_21 http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap0...
  - lelele 16y ago
    Well, it seems a reasonable choice, doesn't it? They provide you with building blocks to get what you want.

c00p3r 16y ago

...and bad implementation, so bad, that all modern web servers and even modern browsers were switched back to asynchronous processes and non-blocking IO. ^_^

unshift 16y ago
bad implementation? asynchronous IO is more efficient than threading simply because it eliminates overhead. i don't think anything was "switched back to" async IO as if threading was supposed to solve some sort of problem with it.
- echaozh 16y ago
  People can actually switch back to "green threads" if pthread implementation is not satisfiable. However, green thread implementations like Erlang are even less popular (by my guess).