I think it's pretty clear, actually...
Posted Nov 2, 2011 21:04 UTC (Wed) by khim
In reply to: libabc: a demonstration library for kernel developers
Parent article: libabc: a demonstration library for kernel developers
This piece of advice is confusing. I think the author meant to make libraries thread-agnostic: don't bend over backwards to accommodate access to the same data from multiple threads, but don't unnecessarily couple different pieces of data either.
The advice is to leave threading issues to the higher-level libraries or to the program itself but to be ready to be called from different threads simultaneously for different datasets. It's explained quite detailed there.
Great advice. We can just use posix_spawn instead: err, wait. How do I call this function under Linux?
Easy: you don't.
The author also should be more specific about pthread_atfork's alleged brokenness.
It's hard to be more specific in a README file. No, really. It's README file, not a PhD thesis. If you'll actually follow the suggested advice and read the POSIX man page you'll see that half of it is dedicated to the detailed explanation for why pthread_atfork should never be used.
Actually, there is a better way: #pragma once (http://en.wikipedia.org/wiki/Pragma_once). It's shorter than traditional header guards (one line versus three), and it eliminates the risk of name collisions.
Sadly it guarantees collisions when your library is embedded in other, bigger, library. #pragma once can be good choice for the application, but it's not acceptable for a library.
Doing work out-of-process gives robustness (and sometimes security) guarantees that are just not possible with calls into libraries.
You know, I think author of PulseAudio will agree with you here - it uses daemon for a reason.
But since there are no way to create "ephemeral context" (no fork/exec, remember) the only way to do that is to create separate daemon which is accessible over some RPC mechanism (dbus, for example).
> separate 'mechanism' from 'policy'
I don't think this phrase means what the author thinks it means.
I think it means exactly what it means. "Price" of a new process may vary wildly in different contexts. If the library creates such processes itself that it embeds the process creation policy - and this is just wrong. Think Android: it's process manager keeps processes around if there are enough resources and kills them if it's under memory or CPU pressure. Library-created processes just mess everything up in such a situation.
to post comments)