>> - how do you find the correct order to acquire locks in the parent process?
>
> One option is to use the import graph to determine call order of atfork handlers.
> If a current std library does not fit into this scheme we can possibly fix it when writing its handlers.
>

Sorry, I fail to see how the "import graph" is related to the correct
lock acquisition order. Some locks are created dynamically, for
example.
That's why I asked for a specific API: when do you register a handler?
When are they called? When are they reset?

>> - what do you do with locks that can be held for arbitrarily long (e.g. I/O locks)?
>
> It is likely that such a lock does not need acquiring at the parent, and re-initializing the library in the child handler will do.

The whole point of atfork is to avoid breaking invariants and
introduce invalid state in the child process. If there is one thing we
want to avoid, it's precisely reading/writting corrupted data from/to
files, so eluding the I/O problem seems foolish to me.

> A  "critical section" lock that protects in-memory data should not be held for long.

Not necessarily. See for example I/O locks and logging module, which
hold locks until I/O completion.