On Wed, Sep 12, 2018, at 16:03, Joseph Sible wrote:
> 2. Most of the time, counting on receiving an EINTR results in race 
> conditions. Our code seems to be affected by this too. Even on glibc, a 
> signal at just the "right" time could result in it not being 
> interrupted. This is why I think moving to an eventfd or something would 
> be better, since we could then use pselect/ppoll/etc. to avoid the 
> signal blocking race.

The race is a good point.

However, switching to eventfd is not trivial. It would be the third locking implementation in python just for pthreads. Using eventfd would require reimplementing all the userspace parts of locking (atomics, appropriate memory barriers, and spinning) ourselves. futex is carefully optimized for userspace locking, whereas I've never heard of normal program locking being done with eventfd before.

If the expected usecase for interrupting locks is user pressing C-c, being 99.99999% correct is probably enough.

So, it's fine with me if you open another issue for reimplementing locks with eventfd. But, I don't personally have the desire to do it.