GNU bug report logs - #78946
30.1; accept-process-output not allowed in threads on macOS

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: John Wiegley <jwiegley <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 78946 <at> debbugs.gnu.org, contact <at> karthinks.com
Subject: bug#78946: 30.1; accept-process-output not allowed in threads on macOS
Date: Mon, 07 Jul 2025 11:28:18 +0200

>>>>> On Fri, 4 Jul 2025 21:20:07 +0100, Alan Third <alan <at> idiocy.org> said:

    Alan> On Fri, Jul 04, 2025 at 01:46:19PM +0200, Robert Pluim wrote:
    >> >>>>> On Thu, 03 Jul 2025 16:00:23 -0700, John Wiegley <jwiegley <at> gmail.com> said:
    >> 
    >> >>>>> Robert Pluim <rpluim <at> gmail.com> writes:
    >> >> John, does it help if you stick something like
    >> 
    >> >> if ([[NSThread currentThread] isMainThread])
    >> >> {
    >> >> }
    >> 
    >> >> around the
    >> 
    >> >> [NSApp run];
    >> 
    >> >> in `ns_select_1'?
    >> 
    John> Hi Robert,
    >> 
    John> With this change, I’m able to run the tests successfully 10,000 times in my
    John> interactive Emacs on macOS.
    >> 
    >> Thatʼs encouraging. Alan, does this change make sense? (Iʼve swapped
    >> out what little I know about the macOS event loop 😀)

    Alan> Not really... The whole thing is a mess. The return here:

    Alan>   if (![NSThread isMainThread]
    Alan>       || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
    Alan>     thread_select (pselect, nfds, readfds, writefds,
    Alan> 		   exceptfds, timeout, sigmask);

    Alan> Was removed and I don't think it should have been, but it was to
    Alan> prevent freezes, apparently... I don't know or recall how this helped,
    Alan> it looks completely wrong to me. Surely that thread_select call should
    Alan> return a result?

I really donʼt get it either: on macOS we run an infinite loop in
`fd_handler', that gets sent messages via a pipe by `ns_select_1' to
run `pselect' (previously only if `ns_select_1' was called from the
main thread, but now all the time).

But apparently itʼs ok to call `pselect' directly (via
`thread_select') from a non-main thread (which is why previously that
return was there for that case).

Itʼs not ok to call the macOS run loop from a non-main thread, which
is where Johnʼs problems came from, but we have to run the run loop
because `fd_handler' returns information using macOS events.

Perhaps we could use a second pipe instead? It would remove the
requirement to go via the macOS event loop, I think.

I think more coffee is needed 😀

Robert
-- 

Previous Next

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