GNU bug report logs - #79334
[PATCH] Don't release thread select lock unnecessarily

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Thu, 28 Aug 2025 21:10:02 UTC

Severity: normal

Tags: patch

Full log


View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79334 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dmitry <at> gutov.dev
Subject: bug#79334: [PATCH] Don't release thread select lock unnecessarily
Date: Fri, 29 Aug 2025 13:31:52 -0400
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  79334 <at> debbugs.gnu.org, Dmitry Gutov
>>   <dmitry <at> gutov.dev>
>> Date: Fri, 29 Aug 2025 09:07:50 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Which brings us to status_notify.  It indeed can close the descriptors
>> > of processes which terminated, so we should probably make it safer.
>> > For example, we could leave alone descriptors marked with non-NULL
>> > waiting_thread if that thread is still alive and is different from the
>> > current thread.  Would that fix the problem?  If yes, I think we
>> > should install such a change.
>> 
>> That was my initial idea for a fix as well.  But I'm not sure about the
>> specific details.  Namely, perhaps we need to be checking waiting_thread
>> everywhere that we're doing FOR_EACH_PROCESS, not just in status_notify.
>> And maybe some new functions/macros should be added to simplify this;
>> maybe a version of FOR_EACH_PROCESS which only iterates over processes
>> for which waiting_thread == current_thread.
>
> You may be right, we should audit all the users of FOR_EACH_PROCESS.
> At least one of them (get-buffer-process) is probably okay as it is,
> but others might need to avoid looking at processes locked to other
> threads, indeed.

While doing this, I had another thought...

Do you know if we have any code which handles the fact that
delete-process might be called on a process while another thread is
calling pselect on its fds?

I don't think we do, which suggests that might also be problematic.
I'll work on a fix which encompasses that as well.




This bug report was last modified 8 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.