Author Birne94
Recipients Birne94, inada.naoki
Date 2017-03-20.20:39:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1490042385.09.0.271616628328.issue29859@psf.upfronthosting.co.za>
In-reply-to
Content
While you might scold me for the following code, it is just some fiddling with the cpython functions from python side.

Backstory is issue 6721 or related to it. I am working on a multi-process service which uses multiprocessing (or rather the billiard fork). While forking I run into deadlocks as described in the issue when I fork while the io lock is acquired.

In order to find a solution I experimented with the cpython module and tried to release the lock manually after a fork. The code can be found attached (tested with python 3.6/3.7 on OSX Sierra). While it does not really do what it is supposed to do, it shows the problem described in this issue (#29859):

If the internal calls to the pthread_* functions fail, I will only get a generic error message:

pthread_mutex_lock[3]: Undefined error: 0
pthread_cond_signal: Undefined error: 0
pthread_mutex_unlock[3]: Undefined error: 0

In reality the produced error messages should be:

pthread_mutex_lock[3]: Invalid argument
pthread_cond_signal: Invalid argument
pthread_mutex_unlock[3]: Invalid argument

This happens because the pthread_* functions do not set the erno variable as described in the issue description.

Please note that the issue is not only related to my code, but might affect all code using locks. While I suppose there shouldn't be any errors when calling the low level functions, the attached patch/pr will make debugging a lot easier when it actually happens by displaying the correct error message.
History
Date User Action Args
2017-03-20 20:39:45Birne94setrecipients: + Birne94, inada.naoki
2017-03-20 20:39:45Birne94setmessageid: <1490042385.09.0.271616628328.issue29859@psf.upfronthosting.co.za>
2017-03-20 20:39:45Birne94linkissue29859 messages
2017-03-20 20:39:45Birne94create