Some thoughts as a followup to  Issue 695643  and Issue 693668 .

We ran into a very subtle bug there due to the fact that a third party library was fork()ing to implement a get_bool() method, hence in a place where we didn't expect.
fork()ing is generally bad because of multithreading, unless it happens in a controlled place, e.g. by the zygote at startup. 
One of the concrete risks, for instance, is that the fork() happens while another thread is doing a malloc() and hence holding the global allocator lock. In that case the forked process will hang at its first malloc call.

Now, the specific problem about gconf/dbus seems to have been fixed, but the lesson learned is: we just found out that third party libraries can fork() in very subtle ways and hence hang chrome. It is not unlikely that some other library will do the same in future (or maybe is already happening, who knows)

It would be great if we could have:
1. A way to prevent forks() from generally happen (i.e. turn them into CHECKs)
2. A way to allow them in a scope (something similar to ScopedAllowIO) for the cases when we feel it's safe to fork() (e.g. zygote)

1) Could be achieved by:
 Option A: interposing fork() and clone() like we do with malloc() and friends and hoping that the third-party libraries don't satically link libc or don't directly do a syscall(NR_clone)
 Option B: registering a pthread_atfork handler
(I prefer B if possible, symbol interposition is always tricky to get right)

Any takers?