Author loewis
Recipients
Date 2006-06-18.18:23:08
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=21627

If I understand correctly, you have Py_END_ALLOW_THREADS
between the system call and the access to errno.
Py_END_ALLOW_THREADS expands to PyEval_RestoreThread, which
calls PyThread_acquire_lock, which (on pthreads) calls
sem_wait, which may set errno to EINTR.

It may well be that the same mistake is made in other
places. That the code is in Python is no proof that it is
"acceptable" - only that earlier reviewers did not catch the
mistake. If so, this should perhaps be discussed on
python-dev: if we want an explicit guarantee that errno
won't change across these macros, we should change the
functions to provide that guarantee.

In general, you should assume that any C library call may
change errno, unless it does not document the values that
errno may receive due to this system call. So for any
library call between the original call and the usage of
errno, you have to analyse whether it may change errno
(directly or indirectly).
History
Date User Action Args
2007-08-23 15:41:19adminlinkissue1102879 messages
2007-08-23 15:41:19admincreate