This is generally pretty awesome, thanks to Lennart and co. for putting this together.
> avoid locking and mutexes, they are very unlikely to work correctly, and incredibly hard to get right.
For serious? Everything in this README is golden advice except for this. Locking can be reasoned about, it's not "incredibly hard", and it's often necessary.
In the context of a shared library, this might not be so bad advice. You don't know how you are going to be used (either by the program tat loads you or by another library loaded by the program).
In such an environment, it's much easier to accidentally create deadlocks that you know nothing about, because you can't predict the invocation pattern of all the libraries and applications potentially linking to you.
I see what you're saying, but that still doesn't mean it's so difficult to get right, it just means you have to think about lock ordering (or just avoid taking > 1 lock at the same time).
> zero global state -- Make your library threads-aware, but not thread-safe!
His point is that even if you have global state and try to protect that using locks, there may be code unknown to your application that works on the same global variables and you may not be able to predict the order of locking.
He specifically mentions the example of NSS (name service switch), which allows you to optionally create and plug in shared libraries that will be invoked without the application or the core C library being modified. So for example, an admin could change /etc/nsswitch.conf to set up LDAP user logins but your application could still use getpwnam(3) without caring about whether the pw retrieved is local, NIS, or LDAP.
> avoid locking and mutexes, they are very unlikely to work correctly, and incredibly hard to get right.
For serious? Everything in this README is golden advice except for this. Locking can be reasoned about, it's not "incredibly hard", and it's often necessary.