Pthreads as a case study of good API design

eli.thegreenplace.net

28 points·ekiru··7 comments

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.

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.

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_chap0...

Well, it seems a reasonable choice, doesn't it? They provide you with building blocks to get what you want.

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

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.

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).

Reply on news.ycombinator.com