GNU bug report logs - #75275
30.0.92; `make-thread` bug on macOS 15.2

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 75275 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 02 Jan 2025 14:05:44 +0100

Alan Third <alan <at> idiocy.org> writes:

> No, none of that needs to run when we're not in the main thread.
> fd_handler run pselect in a separate thread because the NS main thread
> has to run the ns main thread run loop to handle incoming IO from the
> window system.
>
> The NS run loop can emulate parts of pselect, but not the whole thing,
> so we are required to run both the NS runloop and pselect
> simultaneously, hence fd_handler. If we don't need to run the runloop,
> i.e. we're in a non-main thread, then we can just run pselect directly
> and ignore fd_handler.

So IIUC, you'd write this in ns_select_1

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

as return "return thread_select(...)"?

One strange thing about threads having their own event queue is that the
message Stefan sees comes from the NSApplicaiton::run in ns_select_1. Be
that at it may.

(BTW, I've given up on NS completely, meanwhile. Always building
--without-ns.)

Previous Next

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