@vsajip, @gpshead: Would you mind to review this change?

I wrote this change to be able to backport it to stable 3.7 and 3.8 branches.

When bpo-40089 will be fixed, we can enhance the _after_at_fork_child_reinit_locks() in the master branch to use the new _at_fork_reinit() method.

Oh. A colleague working on the glibc tells me that it's unsafe to release the memory of the old lock without destroying it: "Putting two mutexes at the same address could lead to problems".

We should either leak memory or destroy the old lock.

To destroy the old lock, we need to first unlock it if it's lock. pthread_mutex_trylock() can be used to check if it's locked or not. If it's lock, call pthread_mutex_unlock(). Then pthread_mutex_destroy() and pthread_mutex_init().

Sadly, test_manager_initializer() of test_multiprocessing_forkserver hangs with this change :-(

Maybe I should wait for https://bugs.python.org/issue40089 to be fixed first.

Replacing _releaseLock() with _lock._at_fork_reinit() works as expected: test_manager_initializer() doesn't hang.

This approach doesn't work. Since I merged my PR #19195 adding _at_fork_reinit() method to locks, I abandon this PR in favor of PR #19416.