Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 20:31:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 15:31:44 2026
Received: from localhost ([127.0.0.1]:38138 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdaBz-0006Mr-Ti
for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 15:31:44 -0500
Received: from mail-ua1-x92b.google.com ([2607:f8b0:4864:20::92b]:46402)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <shipmints@HIDDEN>)
id 1vdaBw-0006Mg-7E
for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 15:31:42 -0500
Received: by mail-ua1-x92b.google.com with SMTP id
a1e0cc1a2514c-93f69720a7cso1551635241.1
for <80112 <at> debbugs.gnu.org>; Wed, 07 Jan 2026 12:31:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1767817899; x=1768422699; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=Utj1cFFjvOaZAjGRI/RZk306vzgoRPxEFsB1OrgwChc=;
b=DGdMCoGlwee6eZ/qAAtVv7qL4EKwS4L90JjLNrmBRIQkVy/sguvRTRjvJn2EQBN7DM
lv8lvUCwYR9u10uePfd/t6wSLXNmU6kU2+0RGBUMVR9lQz2RfMkwyvWHq51imHwwesI6
kobD4og1Oa0XzG4s2Pl7PixH4Syg+3PhU5/II3ls+imUkpPt+UwNfTck+ULoquoUMzI+
K9AvHTiMwrJmZS0lGhg+qVAJjg2M1CxjcNr/TYiIQDLqMa8dQiuQVMElniap+gfsOsUd
rKLnS+zon4Y2ID3QqZqjaNrsl00PPQ0G8GVZLnGjnx+yGgfq/mTmZPQ8+AYdhiOaZ5MM
+dZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1767817899; x=1768422699;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=Utj1cFFjvOaZAjGRI/RZk306vzgoRPxEFsB1OrgwChc=;
b=J9SnBB7URqtoEbUJYkZ1duOLlM78NN/gwZM6iv94AtSVaGacU06VaeZhI3RSUtjNNN
k0jj6yKGsEz9UPTP05OtqUWHyYbxWI2dEDBlncygNn6sMrrhVDNfJiGIPD3A8Rpo+g/m
7Zg2VnlFem30y8xCr/aEWqJTtf79pA00vmHT1ZWUYEUMy1ocxCdLGnm5txDelqFnTEwT
MNjl6wDQVVCNt5BdJ+Ryhlij0P2NgjoEAMGSxl6QAjw5Gzgdfl/a6ozz0lAzVuAGS+n3
L9nZthGAlUE5HqRwMHeZREOrV6NxaD7R7sze8FwkR2uD7Rl+mFMbcn5PI2slYduyZbZ6
Fckw==
X-Forwarded-Encrypted: i=1;
AJvYcCVaScJIljzoMyphbwG0r0j8Y6bHpCIPu17IANeJYr61qWp0Z+hwGdemSU9kM7M+1vtldKCY+w==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwNtWs+mYal+T3d3BZw3H5zvBMXNVRaTuku0Qsa6PyL2AJT43zE
cN3IECUPwls7jAuF16uM81UBhcLUUzqhK2mmnXM67ikhhZeMqZmVWwBY+iANaCNoaUCeyMqMTE6
wjCs0Dk993cwmG2cGiXmtTlUxGWAyl9E=
X-Gm-Gg: AY/fxX4hVl0RpyFaOXNrtJ+psijUk3PHEFhxz1MQtA0f9VHRmEt98Ro1G2O4K7CyYCU
Pdq0+y13djTTD7+G4Tm6yQ+0v3qbXQ8efMvwxgZERk9d0iGIsHV3utMobCAPm1m13orPuw9rE5p
cpxAp4TnnmVEZ1njZmyzM5/GNwXyhrBCRgh/z7glx2G3p7anuYUKXdnMGdwFHz1cfJVSRve3nu9
dTYG+zugj9BBm7wVX3jRHRwAgrOHsbNoGcbLxJjncSlYMC1q2/xWQFcnkmJAdsRplBZ/nU=
X-Google-Smtp-Source: AGHT+IGhN0U710rE2WBQxx0sKGmyGu5MJTgktqtZYiN0SK4IQI9VzBkSsA+9J1qOc2juhfQHDWsLX83bW7lQARUQe7Y=
X-Received: by 2002:a05:6102:441c:b0:5df:af0f:308c with SMTP id
ada2fe7eead31-5ecb692dc87mr1469812137.38.1767817899293; Wed, 07 Jan 2026
12:31:39 -0800 (PST)
MIME-Version: 1.0
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
<87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN>
<87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN>
<878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN>
<CAN+1HbrkiqXZ0g=ZqzLY4gt7GunJngXvo2qZxFdCGjP+dO9s7g@HIDDEN>
<871pk12psx.GNU's_not_UNIX!-yavor@HIDDEN>
<87zf6p18aq.GNU's_not_UNIX!-yavor@HIDDEN>
In-Reply-To: <87zf6p18aq.GNU's_not_UNIX!-yavor@HIDDEN>
From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN>
Date: Wed, 7 Jan 2026 15:31:27 -0500
X-Gm-Features: AQt7F2oNTNfrY8XBb6X8i-2jnIKU63zYxnyvjrBARqzkc-KjUurQEOTQYeMT5zw
Message-ID: <CAN+1Hbr-db=Rh-S28pbcbAXn2wuDTRDEnGp2O=isvCvQRABdHQ@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
To: Yavor Doganov <yavor@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000ea40440647d22dc6"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org,
alan@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--000000000000ea40440647d22dc6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Jan 7, 2026 at 3:23=E2=80=AFPM Yavor Doganov <yavor@HIDDEN> wrote:
> Yavor Doganov wrote:
> > > $ git apply 80110+80112.patch
> >
> > Hmm, the patch is based on commit b5b7504, there's only d5b9fc5 on top
> > which touches etc/NEWS so it shouldn't cause conflict.
> >
> > I'll try with a fresh checkout, maybe I messed up something.
>
> The patch applies on a fresh checkout (top commit is d5b9fc5) so it
> should be something on your end, it seems.
>
> $ git branch
> * master
> $ git describe
> emacs-30.1-180158-gd5b9fc55792
>
I tried again to no avail. My checkout is fresh and freshly configured and
built after an extraclean.
Here's a verbose apply in case this sparks a reason it doesn't apply.
$ git apply --verbose 80110+80112.patch
Checking patch src/nsterm.m...
error: while searching for:
if (writefds && FD_ISSET(k, writefds)) ++nr;?
}?
?
/* emacs -nw doesn't have an NSApp, so we're done. */?
if (NSApp =3D=3D nil)?
return thread_select (pselect, nfds, readfds, writefds, exceptfds,?
timeout, sigmask);?
?
if (![NSThread isMainThread]?
|| (timeout && timeout->tv_sec =3D=3D 0 && timeout->tv_nsec =3D=3D 0)=
)?
thread_select (pselect, nfds, readfds, writefds,?
exceptfds, timeout, sigmask);?
else?
{?
struct timespec t =3D {0, 0};?
thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);?
}?
?
error: patch failed: src/nsterm.m:5066
error: src/nsterm.m: patch does not apply
--000000000000ea40440647d22dc6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">=
On Wed, Jan 7, 2026 at 3:23=E2=80=AFPM Yavor Doganov <<a href=3D"mailto:=
yavor@HIDDEN">yavor@HIDDEN</a>> wrote:</span></div></div><div class=3D=
"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Yavor Doganov wrote:<br>
> > $ git apply 80110+80112.patch<br>
> <br>
> Hmm, the patch is based on commit b5b7504, there's only d5b9fc5 on=
top<br>
> which touches etc/NEWS so it shouldn't cause conflict.<br>
> <br>
> I'll try with a fresh checkout, maybe I messed up something.<br>
<br>
The patch applies on a fresh checkout (top commit is d5b9fc5) so it<br>
should be something on your end, it seems.<br>
<br>
$ git branch<br>
* master<br>
$ git describe<br>
emacs-30.1-180158-gd5b9fc55792<br></blockquote><div><br></div><div class=3D=
"gmail_default" style=3D"font-family:monospace">I tried again to no avail.=
=C2=A0 My checkout is fresh and freshly configured and built after an extra=
clean.</div><div class=3D"gmail_default" style=3D"font-family:monospace"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:monospace">Here&#=
39;s a verbose apply in case this sparks a reason it doesn't apply.</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace">$ git apply --ve=
rbose 80110+80112.patch<br>Checking patch src/nsterm.m...<br>error: while s=
earching for:<br>=C2=A0 =C2=A0 =C2=A0 if (writefds && FD_ISSET(k, w=
ritefds)) ++nr;?<br>=C2=A0 =C2=A0 }?<br>?<br>=C2=A0 /* emacs -nw doesn'=
t have an NSApp, so we're done. =C2=A0*/?<br>=C2=A0 if (NSApp =3D=3D ni=
l)?<br>=C2=A0 =C2=A0 return thread_select (pselect, nfds, readfds, writefds=
, exceptfds,?<br> =C2=A0timeout, sigmask);?<br>?<br>=C2=A0 if (![NSThrea=
d isMainThread]?<br>=C2=A0 =C2=A0 =C2=A0 || (timeout && timeout->=
;tv_sec =3D=3D 0 && timeout->tv_nsec =3D=3D 0))?<br>=C2=A0 =C2=
=A0 thread_select (pselect, nfds, readfds, writefds,?<br> =C2=A0 exceptfd=
s, timeout, sigmask);?<br>=C2=A0 else?<br>=C2=A0 =C2=A0 {?<br>=C2=A0 =C2=A0=
=C2=A0 struct timespec t =3D {0, 0};?<br>=C2=A0 =C2=A0 =C2=A0 thread_selec=
t (pselect, 0, NULL, NULL, NULL, &t, sigmask);?<br>=C2=A0 =C2=A0 }?<br>=
?<br><br>error: patch failed: src/nsterm.m:5066<br>error: src/nsterm.m: pat=
ch does not apply<br></div></div></div>
--000000000000ea40440647d22dc6--
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 20:28:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 15:28:16 2026 Received: from localhost ([127.0.0.1]:38084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vda8e-00065X-0z for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 15:28:16 -0500 Received: from dane.soverin.net ([185.233.34.148]:38237) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vda8b-00064y-5H for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 15:28:14 -0500 Received: from smtp.soverin.net (unknown [10.10.4.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4dmfjy5Ty9z1Rc; Wed, 07 Jan 2026 20:28:06 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4dmfjy1TTzz3Q; Wed, 7 Jan 2026 20:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1767817686; bh=OwmhEH5DdkPJvPjWm28MYqJSUqKHIdMOMjj8lFYcjVU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MxJmnpLA9synvW320vs9rcthXgMHPoYaIyTrHoBf86tZG07HOkQOUDEtTW12yu6PK XXtwMKLnN3p4km4PjQZV6yCm+gZdh49Khu+e28/JIeZK08oAkECiDo8FjXw1yf4dDU gkqs4MfnhfoixS3idDWKCXzft02qK1Ah6dQoIpQbjzRUTrT8pFJTsgLRrl2X5U+tQU mrroekonIZcGcKWCBv//quSoblVHHn3K+SQP/ZeeU7UqSsbk7KfIAbgHbPqqz6X1Kg bqhcvT9StLSlPNbT6Jsiw63yxxqNaXaBDP3EoMtf5USKXvCQfpo/s7T+hXtqXoL5R/ +3fDTAG2gEIIw== X-CM-Envelope: MS4xfICFgBBXRdPGbhqPmjpDJJ6kI7vVpou0Df8Cc+13TKw2x6pEkXX0Qs9J7DAQMwrvcWMgZCNigT8St7jRW7fCWBYmlVGk3UBT36/IYb7b4Zge91FLvOeX WzsuEolfGtEZzrQ0RLZFQAFxea7M+CRwWouoYp/EX+kVaitJJ56OAptqZMwmfYEeo4Urt6ha6tYnBZRKTldktiJXDJJLuLjR1qBPzWDG63BhdbEQW/4Qw0lR i39rPmDJfTcTkwKGKicoJLoEsG3hPHN2V5hFUtnrK2NX/2tkgk5u9ojTr0/sT2cgbFBvqPHwSKlvOeySo2cZ08jhXSqaDvX2jQ6zJ0rAeso= X-Soverin-Id: 019b9a25-2bf0-7fd9-b595-454b318e865d Received: from localhost (namib [local]) by namib (OpenSMTPD) with ESMTPA id 3477b793; Wed, 7 Jan 2026 20:28:05 +0000 (UTC) Date: Wed, 7 Jan 2026 20:28:05 +0000 From: Alan Third <alan@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it Message-ID: <aV7B1fRfWLavbL-1@HIDDEN> Mail-Followup-To: Alan Third <alan@HIDDEN>, Yavor Doganov <yavor@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN References: <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <aV2K9IfRz6DAQTNZ@HIDDEN> <877bttfqlb.GNU's_not_UNIX!-yavor@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877bttfqlb.GNU's_not_UNIX!-yavor@HIDDEN> X-Spampanel-Class: ham X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80112 Cc: Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Wed, Jan 07, 2026 at 04:24:32PM +0200, Yavor Doganov wrote: > Alan Third wrote: > > > if (NSApp == nil > > > || ![NSThread isMainThread] > > > || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) > > > return thread_select (pselect, nfds, readfds, writefds, > > > exceptfds, timeout, sigmask); > > > > I think we need to remove the test of whether the timeout is zero, > > because even if the timeout is zero we still need the NS runloop to > > run. > > This sounds logical to me; I was wondering why it is there and what is > its purpose. It was added by Jan Djärv in commit ddee651 (August > 2012) during yet another redesign of this complex mechanism (that's > when the fd_handler thread appeared). It is difficult for me to read > the diff though, perhaps you can take a look if you have time. Looking at the change gives me no more insight. It doesn't appear to follow from the tests in the old if statement, and it still doesn't make much sense to me as a new addition. I guess he maybe thought it was the right thing to do so that ns_select wouldn't take much longer than the timeout requested... -- Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 20:23:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 15:23:51 2026 Received: from localhost ([127.0.0.1]:38040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vda4M-0005oV-Vt for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 15:23:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46564) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vda4I-0005oC-Gd for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 15:23:50 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vda4C-0005TK-4k; Wed, 07 Jan 2026 15:23:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=0XDvpjJsIkIamMPk/7esLD1wYaBDucexuvkM7QiOsDw=; b=dZee2Vf/2qN/od3hTquv oznOr4VE2c28VGUBaGvhYMtrUdzCtHmQcyexHwinUoY24JHru7W1H93j5oTjXug4di0gniRiCuurx OmKLCSLRry0a737bw/YNfvgnzj5OALuTyLxqH5K+5c1TDj7vMix9A5N0oBAchxX0S21fpVUQbZDi8 esIgtpbjFRtUO9IivsCSa0EoEyd9onnBejvgFdyyGv63WuGMbEZEppeadb0yNrdnU6f3wg6Alm+j4 kKDpbGDEeZwZ9cuWqevd/EJj5SDAu21Li1carNh6DxsSmWoEfMbMhoF/uoJDsUmSI9Ny+84fU+7vd J3PiJcSWcDToRA==; Date: Wed, 07 Jan 2026 22:23:25 +0200 Message-ID: <87zf6p18aq.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: =?UTF-8?B?U3TDqXBoYW5l?= Marks <shipmints@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <871pk12psx.GNU's_not_UNIX!-yavor@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN> <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> <CAN+1HbrkiqXZ0g=ZqzLY4gt7GunJngXvo2qZxFdCGjP+dO9s7g@HIDDEN> <871pk12psx.GNU's_not_UNIX!-yavor@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: kaloian@HIDDEN, Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, alan@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Yavor Doganov wrote: > > $ git apply 80110+80112.patch > > Hmm, the patch is based on commit b5b7504, there's only d5b9fc5 on top > which touches etc/NEWS so it shouldn't cause conflict. > > I'll try with a fresh checkout, maybe I messed up something. The patch applies on a fresh checkout (top commit is d5b9fc5) so it should be something on your end, it seems. $ git branch * master $ git describe emacs-30.1-180158-gd5b9fc55792
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 19:21:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 14:21:03 2026 Received: from localhost ([127.0.0.1]:37843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdZ5a-0002pE-Vu for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 14:21:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdZ5Y-0002oS-1K for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 14:21:00 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vdZ5R-0000y8-Qd; Wed, 07 Jan 2026 14:20:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=gzgCTP6bMiE/TBRwkyvpbu8vbxmD7N2sdNPmlSaNZqw=; b=D7Q9qiKtZKxJA0PObF+A sQ2z80BWat1gLKRwcFGp7NOnmA2sW+PcrqjLRjK4pWfXUXqxSKkmekXSkx0SqhOaX6OBcjPonao57 VB3Bhd9VBI/1nYkPb3CHFf4LsK7YPEH1MpC36Zar5K50CHHB0/JnkViFRM1ZCWEopLZfUZWss1vXR Kp4qQO9NimD3WPVvyyc+rGwxBgFJE1oRjhinWPIr9JeBWKicjDrMbJBnAr+x15lY9w3TPdm1aup+p bIVpeUbPHtYanPxXjljdhH9thtH7cWVGtVDMO2Vxc0xepTQtHBlSJyKNYzQNyq8hAd/gOCpoC+u/x bZ6H4vliZCuRpA==; Date: Wed, 07 Jan 2026 21:19:58 +0200 Message-ID: <871pk12psx.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: =?UTF-8?B?U3TDqXBoYW5l?= Marks <shipmints@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <CAN+1HbrkiqXZ0g=ZqzLY4gt7GunJngXvo2qZxFdCGjP+dO9s7g@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN> <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> <CAN+1HbrkiqXZ0g=ZqzLY4gt7GunJngXvo2qZxFdCGjP+dO9s7g@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: kaloian@HIDDEN, Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, alan@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stéphane Marks wrote: > Offering to test on my macOS 12 and 26 boxes but the patch doesn't > apply for me on latest master. This command succeeds for me (after I revert the local changes): > $ git apply 80110+80112.patch > Perhaps a rebase? Hmm, the patch is based on commit b5b7504, there's only d5b9fc5 on top which touches etc/NEWS so it shouldn't cause conflict. I'll try with a fresh checkout, maybe I messed up something.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 18:59:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 13:59:20 2026 Received: from localhost ([127.0.0.1]:37780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdYka-0001kn-4C for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 13:59:20 -0500 Received: from mail-vs1-xe2d.google.com ([2607:f8b0:4864:20::e2d]:55699) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vdYkU-0001kX-U7 for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 13:59:18 -0500 Received: by mail-vs1-xe2d.google.com with SMTP id ada2fe7eead31-5dd88eef2f3so865813137.3 for <80112 <at> debbugs.gnu.org>; Wed, 07 Jan 2026 10:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767812354; x=1768417154; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oP42czNLfzhjTl2qa100RZ1FSxQjnL8jLYU/MXNL5lE=; b=Qokxkx9VOtlBrXriHGY/xy9AhcsRVYMgF9HxdoXG9CEbw3jW/IDBAJSBjvzrrOkaGr 1JkIjqwbE6RX9Gs3e3DeYKzZff4Toin7BI+IWgwpJJy/noB4T+cyuT9aWbjMoxmFtXSk A2WN7vZdXfQ7MeMdgIL+dYWQFORTz1GQypipwcuc7KFLBsllFiRNMtmIS1fWCk96VQfy FF8447Gw7Ri8xCEZbgFi9ZoHXXkbSNxnAWsZkPuDZkJKJoT/rdUE954EuX2q+UFgri+t kX0oUyKBiURWOsilKGvqJNQYCAoepSg7Ty/wi8B10UBxrPDgyXy232Hw2wrCxjSWIPjh QspQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767812354; x=1768417154; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oP42czNLfzhjTl2qa100RZ1FSxQjnL8jLYU/MXNL5lE=; b=OkKHGMp9WARoA4cz6UUuN+CkwWb4EHXVZT3Rc6j1HV7WwgBTgMfunMkXZp2T2IHAYk /PAn4HRjcFrbSjwb0S5Ubkk2GE5TaPENSJYNnfrs7ajFX+ev3G8i1+KvYaej+oR7CjtP 3TwxFHLCJUNycJkE/m4dxQgJlkR4jdVVYzpJmwQQp2EOPvozkQ9RzYBRzOMKWJzYJy4a eHYvgs6ArGzIBkkSbu/at8NG2dzfCLFIMsho5jEya2OHbH9l5isFeWepJjLfJBUeT2ca HI1U4RvUoJ0v1m20oZ41DdfzIlyoWBn+tIdPD0+jtgxltTgQROnw+5jKFjt2G5oGpPeL 6Hyw== X-Forwarded-Encrypted: i=1; AJvYcCUrjxvfjATDRHvQsErzYlKZe30yQ+RZKL9F7eS36FntZ5oZMZHAbRyIRBAumAr7AvhHKDNvsw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw1eEbmZQLQHwpnfwl+B3o5xrlkHSoxLxyNIop56uLNwCfQdV/H SONKoLZC3MK5RtsSvLK5Qod6aZlKIkIeV0ltAxIFc/F+XHv4vPv9azNY+WbUMDkf0pt8K1quWYU hlaaE1lwSWYgLqzvdmak5xE2sCikuSTQ= X-Gm-Gg: AY/fxX4/hEnbbmJM8RshOkshaKh7iER+TYObJeh1T+VuYxWPiKNLvgOfr4WiB83eWD0 MahCSohJOvxfP7GXN9LGrZxBZ6yRFayFbKJvI0HYrS9dNdULI0GQ1HE7LFk6auQV5zgfmAP+jAX IsJhq3PRqTZGSioNNPHSh+LwsxZSvTpSYZVTD9vtf/x9sPwPdy9F7sqTObNrjo5wmAQ04GfVP/H xezhOvEMGR79QUnKDj0p32kRCjgVcuothKgctEDmTGZddoAvRHE/4wQ8YJgFV0TyLhVs/4= X-Google-Smtp-Source: AGHT+IEr/dumlQPLPdznrhX6A4M3aILT5w3/Zw7kQSja5gp6R1kLwY3+m1W6cQklQ0FN0rtsP/u8Wz9ynkijndSM2yY= X-Received: by 2002:a67:e7ca:0:b0:5df:c1f6:be44 with SMTP id ada2fe7eead31-5ecb5cbb79bmr1363538137.5.1767812352569; Wed, 07 Jan 2026 10:59:12 -0800 (PST) MIME-Version: 1.0 References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN> <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> In-Reply-To: <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Wed, 7 Jan 2026 13:59:00 -0500 X-Gm-Features: AQt7F2ohqwEgB9s4ipnAHVMyrw1LmzONzp-pF3sPLQZpqpKReUZYmQG4K1Cc5PE Message-ID: <CAN+1HbrkiqXZ0g=ZqzLY4gt7GunJngXvo2qZxFdCGjP+dO9s7g@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it To: Yavor Doganov <yavor@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000004df4590647d0e3bb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80112 Cc: kaloian@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org, alan@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000004df4590647d0e3bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 7, 2026 at 9:08=E2=80=AFAM Yavor Doganov <yavor@HIDDEN> wrote: > Eli Zaretskii wrote: > > > The patch I proposed at #80110 fixes it, > > > > So I guess we install both changes? > > That would be great. > > > But please be sure to run test/src/thread-tests.el, > > test/lisp/thread-tests.el, and test/src/process-tests.el from the test > > suite, after applying both changes, and see if any of these tests fail > > in some weird manner. > > They all pass for me on GNU/Linux but ideally the change should be > tested by someone on macOS (both by running Emacs and running the > tests). I attach the full patch for completenes. > Offering to test on my macOS 12 and 26 boxes but the patch doesn't apply for me on latest master. $ git apply 80110+80112.patch error: patch failed: src/nsterm.m:5066 error: src/nsterm.m: patch does not apply Perhaps a rebase? --0000000000004df4590647d0e3bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Wed, Jan 7, 2026 at 9:08=E2=80=AFAM Yavor Doganov <<a href=3D"mailto:= yavor@HIDDEN">yavor@HIDDEN</a>> wrote:</span></div></div><div class=3D= "gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">Eli Zaretskii wrote:<br> > > The patch I proposed at #80110 fixes it,<br> > <br> > So I guess we install both changes?<br> <br> That would be great.<br> <br> > But please be sure to run test/src/thread-tests.el,<br> > test/lisp/thread-tests.el, and test/src/process-tests.el from the test= <br> > suite, after applying both changes, and see if any of these tests fail= <br> > in some weird manner.<br> <br> They all pass for me on GNU/Linux but ideally the change should be<br> tested by someone on macOS (both by running Emacs and running the<br> tests).=C2=A0 I attach the full patch for completenes.<br></blockquote><div= ><br></div><div class=3D"gmail_default" style=3D"font-family:monospace">Off= ering to test on my macOS 12 and 26 boxes but the patch doesn't apply f= or me on=C2=A0latest master.</div><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><br></div><div class=3D"gmail_default" style=3D"font-fa= mily:monospace">$ git apply 80110+80112.patch<br>error: patch failed: src/n= sterm.m:5066<br>error: src/nsterm.m: patch does not apply</div><div class= =3D"gmail_default" style=3D"font-family:monospace"><br></div><div class=3D"= gmail_default" style=3D"font-family:monospace">Perhaps=C2=A0a rebase?</div>= </div></div> --0000000000004df4590647d0e3bb--
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 17:36:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 12:36:55 2026 Received: from localhost ([127.0.0.1]:37611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdXSp-0005Pd-1B for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 12:36:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38784) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdXSm-0005PP-0i for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 12:36:52 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vdXSf-0002Ti-Sx; Wed, 07 Jan 2026 12:36:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=c1hG4nZLGt7HyTHq2SRDmu9cyBXUkQ3dm34wISUgSyo=; b=dkstx2mEhllZxZVEW+Oj mcJ2NrVTvSahXmSN8ZII8Fh1zbJvyqchmmv/PMFPc7qEPBJv7VCCdVQ8J6GzNLDPV2srMZnJpUmwC Z+0vYl3qz8Q9tpmZMvWBooyJrer8wqGqEl657b2RmWj08qBjQi123p6SSpRm5l1S0iZ2TjK/zClXP OKAOA1Hrrwj9yDoQzwO79wIvOPhHjdxHV+ywx7/dzr8s4t93yTahl2mTqIWcnNqTfzUJXN9EPyWtl v57xIAsEi4fTbwbRzSehSR2cmDy1c8IZV0NVNUxouwcK2Jsg0FPl6ucAZBJ8bzB8YYhuvxe/adpvW 0/No5lq4cc6duQ==; Date: Wed, 07 Jan 2026 19:36:33 +0200 Message-ID: <87jyxtpboe.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <86fr8hcwjz.fsf@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN> <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> <86fr8hcwjz.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: kaloian@HIDDEN, Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, alan@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii wrote: > > From: Yavor Doganov <yavor@HIDDEN> > > P.S. It looks like there is no way to run the tests with an > > out-of-tree build, is that correct? > > How did you try to do that with an out-of-tree build? I followed the last example in test/README: make src/thread-tests But after reading the generated test/Makefile I figured out that I have to use "make -C", cd to the test directory or just make test/src/thread-tests. Sorry for the stupid question.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 14:44:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 09:44:47 2026 Received: from localhost ([127.0.0.1]:35413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdUmF-00025G-IC for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 09:44:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39558) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vdUmD-000252-AF for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 09:44:45 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vdUm7-0008SR-1d; Wed, 07 Jan 2026 09:44:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7qAnt/lK7PyWHfn+Kmxtd4LUaYMdgaTlBhyK++VswAE=; b=Q0p92s3eoxFX +0spKb7NCkuibVvZhq8cceVHqGIUwuonk5MBH55j9IcK9n7N0yEv+pZAgCpebjr3kXQ/aVbWHPum2 wIX8VXpzz5K3rt1KE0YMD9SxjAHmMXq3K2I72hsbITiLThVXWk2HlU93WMWGZH8OZEx3z/K8UjFeF LtchIBCOmlntuj7ibYI9VhN0y1Iw6XAO3lHqxETx+iW4azaGUnBalXYBwAK0PJLO6dXpJFc55tV27 SFSSqDLcXMExH+rRx6i/lGusDuAstg0jM5pPPqqLCPEececAsYJUi5/nw5qOJ9GYCtRS2FTr/lGvr I/Tf9Gjx94cwQ3BKC+XF5A==; Date: Wed, 07 Jan 2026 16:44:00 +0200 Message-Id: <86fr8hcwjz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> In-Reply-To: <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Wed, 07 Jan 2026 16:07:52 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN> <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: alan@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Wed, 07 Jan 2026 16:07:52 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: Yavor Doganov <yavor@HIDDEN>, > alan@HIDDEN, > kaloian@HIDDEN, > 80112 <at> debbugs.gnu.org, > shipmints@HIDDEN > > Eli Zaretskii wrote: > > > The patch I proposed at #80110 fixes it, > > > > So I guess we install both changes? > > That would be great. > > > But please be sure to run test/src/thread-tests.el, > > test/lisp/thread-tests.el, and test/src/process-tests.el from the test > > suite, after applying both changes, and see if any of these tests fail > > in some weird manner. > > They all pass for me on GNU/Linux but ideally the change should be > tested by someone on macOS (both by running Emacs and running the > tests). I attach the full patch for completenes. Thanks. Could someone try that on macOS and report back? > P.S. It looks like there is no way to run the tests with an > out-of-tree build, is that correct? How did you try to do that with an out-of-tree build?
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 14:24:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 09:24:48 2026 Received: from localhost ([127.0.0.1]:35270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdUSu-0000tP-H8 for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 09:24:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38808) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdUSr-0000t7-Oq for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 09:24:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vdUSl-0003HF-La; Wed, 07 Jan 2026 09:24:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=254XfggRmNzv2v+fDMk0wXAR0xUP+L/aV23lMba2sSA=; b=ML5lzXuBvJxiBAcg2EfX wEA/ZnAjgZP6Gsuencj++PL3mfNNUHKEy/hs6N3+pgMFyVf5Y1UFGfN5vznZ2VmtvW4vRYdNNbDRk cwFxYCl5yLkA4B6PfTd2JQo7aG6xq/HF2OiU1+IaGUkcn7Tkep/qvBQ0hoqCUZL5g09rwuZiooV3q wSM7yiPpb0Zi0QYGqsjZpbLWCbAenfGhwcfV8Qv5VjAAHIDtquxaPljrumiIUEH8o34iGPIZcb7kq XAWsT6Mnp42iYxX42obAUbTtus1Jpqkt1OD/DNmQO41jQvTta3T/tMm3aqo6qQ9B4TBLlzh6ESGS5 AGhsVkdUJT8BJQ==; Date: Wed, 07 Jan 2026 16:24:32 +0200 Message-ID: <877bttfqlb.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Alan Third <alan@HIDDEN>, Yavor Doganov <yavor@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <aV2K9IfRz6DAQTNZ@HIDDEN> References: <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <aV2K9IfRz6DAQTNZ@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Alan Third wrote: > > if (NSApp == nil > > || ![NSThread isMainThread] > > || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0)) > > return thread_select (pselect, nfds, readfds, writefds, > > exceptfds, timeout, sigmask); > > I think we need to remove the test of whether the timeout is zero, > because even if the timeout is zero we still need the NS runloop to > run. This sounds logical to me; I was wondering why it is there and what is its purpose. It was added by Jan Djärv in commit ddee651 (August 2012) during yet another redesign of this complex mechanism (that's when the fd_handler thread appeared). It is difficult for me to read the diff though, perhaps you can take a look if you have time. I tested with this test removed and couldn't find any obvious problems (tried network-intensive packages, clicking around the menus and moving the scrollbars). Emacs is responsive and everything appears to be working normally, including Lisp threads. I also ran the tests Eli said should be run, they all pass.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 14:08:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 09:08:26 2026
Received: from localhost ([127.0.0.1]:35210 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdUD3-0008WN-7r
for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 09:08:25 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:54632)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdUD0-0008W3-6J
for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 09:08:22 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>)
id 1vdUCu-0007o5-4V; Wed, 07 Jan 2026 09:08:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From:
Date; bh=N+wjfwLqI1TtprD3g9VBgQBGvx5e13q6QqybwWHEnmg=; b=FKpkBcU6d0A1fmUeQClN
c19mWLK1bRw6Y5E+XOYIwaSRgMYmoaXsvB3B9D9tDQ6+as+aT30FhquuMwhFTSIADCZ0jswTQZBdb
0BnsVx0dSWZ0qHtStNroZhbJvWkbN2/HaY6b6VqVDAUha/Se6kI7XdmxBfgFRgrWXI7Ibqyhf8/Vc
fiUpT5bTieorjjY2l65gc7fzEMRJM1aV5O8fB+JSO1b17HBT5hPaIvpGl3Kmw5wI9fcTamqa/J3nq
g/q/HbsHq64rhvotnsXXRHljwOF7d8zE3q+woKT5la3Wb95vPlMAUpneF2XiSk8WtBqqGWpJx1VfG
UvANNK3BMMyPlQ==;
Date: Wed, 07 Jan 2026 16:07:52 +0200
Message-ID: <878qe9frd3.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
In-Reply-To: <864ioyebbx.fsf@HIDDEN>
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
<87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN>
<87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> <864ioyebbx.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: multipart/mixed; boundary="Multipart_Wed_Jan__7_16:07:52_2026-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org,
alan@HIDDEN, shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--Multipart_Wed_Jan__7_16:07:52_2026-1
Content-Type: text/plain; charset=US-ASCII
Eli Zaretskii wrote:
> > The patch I proposed at #80110 fixes it,
>
> So I guess we install both changes?
That would be great.
> But please be sure to run test/src/thread-tests.el,
> test/lisp/thread-tests.el, and test/src/process-tests.el from the test
> suite, after applying both changes, and see if any of these tests fail
> in some weird manner.
They all pass for me on GNU/Linux but ideally the change should be
tested by someone on macOS (both by running Emacs and running the
tests). I attach the full patch for completenes.
P.S. It looks like there is no way to run the tests with an
out-of-tree build, is that correct?
--Multipart_Wed_Jan__7_16:07:52_2026-1
Content-Type: text/plain; type=patch; charset=US-ASCII
Content-Disposition: attachment; filename="80110+80112.patch"
Content-Transfer-Encoding: 8bit
diff --git a/src/nsterm.m b/src/nsterm.m
index fe5bc35086d..abf0823b084 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -5066,18 +5066,14 @@ Function modeled after x_draw_glyph_string_box ().
if (writefds && FD_ISSET(k, writefds)) ++nr;
}
- /* emacs -nw doesn't have an NSApp, so we're done. */
- if (NSApp == nil)
- return thread_select (pselect, nfds, readfds, writefds, exceptfds,
- timeout, sigmask);
-
- if (![NSThread isMainThread]
+ if (NSApp == nil
+ || ![NSThread isMainThread]
|| (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
- thread_select (pselect, nfds, readfds, writefds,
- exceptfds, timeout, sigmask);
+ return thread_select (pselect, nfds, readfds, writefds,
+ exceptfds, timeout, sigmask);
else
{
- struct timespec t = {0, 0};
+ struct timespec t = {0, 1};
thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
}
--Multipart_Wed_Jan__7_16:07:52_2026-1--
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 12:45:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 07:45:12 2026
Received: from localhost ([127.0.0.1]:34941 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdSuV-0004UG-Hg
for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 07:45:12 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:45112)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vdSuS-0004Q5-Pn
for 80112 <at> debbugs.gnu.org; Wed, 07 Jan 2026 07:45:10 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vdSuJ-0004Ez-R8; Wed, 07 Jan 2026 07:45:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=E2MNPgmYfx3bE7QWgwfDlOkEvKcgr6EfQLJyyUSikFU=; b=EekI5mZf0JZa
UJcOnnmbE3Nw8WzBBe5yU3b+0HeIyWOiPpkAGUu1jZEAHbZczv4tOnniGRlPVp8+hVtl9fuZ0Axci
+w+3nA1Ki+hbrwCxKRxKJFsrZcASMNC8cqvnnLfh4G8aHSmvm7C4skyAZ9nXwVqpNaTKKtplYG1bu
yRPMEGvjc8CcIlx26hOxR8D15jrcNAyjemB12NseYMiqaKTEF4yvsdAZnFRHngyznKRdF+TQD/4EI
Sx7RD9EFpZr8yhJ5DxqSRt34LocL9Ld/CBbnBvr8nirrAVFl1rSfWWkeksoP+j9M7MZKZOJCzS4Hc
zbZHAy1bWCIC6N0iT3+URw==;
Date: Wed, 07 Jan 2026 14:44:49 +0200
Message-Id: <86zf6pd22m.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Third <alan@HIDDEN>
In-Reply-To: <aV2K9IfRz6DAQTNZ@HIDDEN> (message from Alan
Third on Tue, 6 Jan 2026 22:21:40 +0000)
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
References: <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN>
<86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN>
<86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN>
<86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN>
<86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN>
<aV2K9IfRz6DAQTNZ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Tue, 6 Jan 2026 22:21:40 +0000
> From: Alan Third <alan@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, kaloian@HIDDEN,
> 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
>
> On Tue, Jan 06, 2026 at 09:31:51PM +0200, Yavor Doganov wrote:
> > Eli Zaretskii wrote:
> > > > Yes, I confirm that setting it to {0, 1} is enough to fix the
> > > > problem
> > >
> > > Thanks.
> > >
> > > Does this also fix bug#80110, fingers crossed?
> >
> > No, as I said earlier in this discussion (when I mentioned that
> > defining release_select_lock to sleep fixes the bug), when Lisp
> > threads are working it is extremely easy to reproduce the freeze.
> >
> > The patch I proposed at #80110 fixes it, and perhaps the change should
> > be made for both NS implementations. If so, it should be merged with
> > the (NSApp == nil) condition as was in Adrian Robert's original code:
> >
> > if (NSApp == nil
> > || ![NSThread isMainThread]
> > || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> > return thread_select (pselect, nfds, readfds, writefds,
> > exceptfds, timeout, sigmask);
>
> I think we need to remove the test of whether the timeout is zero,
> because even if the timeout is zero we still need the NS runloop to
> run.
Maybe. But let's do it one change at a time, okay? Let's first make
only the two changes we were discussing here and in bug#80110, then
see if there are more problems with threads (by running the relevant
test-suite tests), and only after that make this change and compare
what we get with what we had before the change.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 7 Jan 2026 08:36:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 07 03:36:59 2026 Received: from localhost ([127.0.0.1]:34435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdP2I-0006qS-PX for submit <at> debbugs.gnu.org; Wed, 07 Jan 2026 03:36:59 -0500 Received: from fout-a5-smtp.messagingengine.com ([103.168.172.148]:60415) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <kaloian@HIDDEN>) id 1vdB3N-00015O-Jj for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:41:11 -0500 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 13536EC00FB; Tue, 6 Jan 2026 12:41:04 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Tue, 06 Jan 2026 12:41:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doganov.org; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1767721264; x=1767807664; bh=H44CxkvbBA b3XF/8NeKT5OIboPQEUcXj5A6MLegRWqE=; b=BAAQM3K4tDT9xD/eq5K26uqCoH PsN2dhGid46grjk7npNQRSY/uxsowdUzWpt5786lEt94b/bFbLcynKt68Wch+RB2 SPlUnezM8z7x19hFDCE3lIvwebigQ0svc3MkRQsvmqoI0uQa8BqW1Zz6TtBa5w8M bPCRa81EZKAvMniWDQXDP/ExYErmu6Hl9MBHNJBgKvP8h6T8H0h/enfCu9zoao28 1EauOISavo+2slcnoVh9SZZWRt94pj2dAReCrhhg3S1vTAofwkbpTPaxPBUvQ+wE atfjyvyO6mRZS3d5ul04yCis89ZAVHy5JPiO+1XO56RYX/4EPL5QffwqMewA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1767721264; x=1767807664; bh=H44CxkvbBAb3XF/8NeKT5OIboPQEUcXj5A6 MLegRWqE=; b=m2IiWFptY9sSH2bp+Xv6anlgqtap27gCIVKHKaj8nVeibmT5aJU MGwea2ecIhyDBior4NSrRMtbLCjjC17qmrt7g8JaVBsV4v3hDd/CQYLAEVZvz0l/ /csXNnDYIooV/SiJifaZC1eWGj+12L5zurmbELJDsN+FI1UOq1xTHQSNSJKUjBtI xN0hfmxvfZ3AcGOduQafroCpKLze2Z7+fN39CQDU9ls6cnC9NZV8K60xxdC07NE9 5uhdRAqOx/mA28bl63icmGOUD8SVcQvZU+iHdZGdu62IiqF8rXSJlr3roAEhXVdR dHhSIWjYk5wlSYhgrZn9j99x6ztaUaAhtjQ== X-ME-Sender: <xms:L0ldaa22bVqPqxU5NA_jkeF09HNPmF1yIQI8eojj4Co-aAmQ-OZqLQ> <xme:L0ldaQx3w3fG50Jin6AmBnPr05R6zO9QDNSRZaNiaoL8cS9PjgGaN-BY_at4cMZe2 T_OpMhnR-LlWyttxBP5XeFqSr-MrbBdg54byU2b8fENpQcxuAvrajg> X-ME-Received: <xmr:L0ldacvSAQuGHCT63P0HtOkF0JdX3Icxstb7k3EPuQNEAc0P0Gq-7nurBR4bEkn0-txbV5LG1i2JrV7asaddSqDF> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutddtkedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffkhffvufgjfhgfgggtsehttdertddtredvnecuhfhrohhmpefmrghlohhirghn ucffohhgrghnohhvuceokhgrlhhoihgrnhesughoghgrnhhovhdrohhrgheqnecuggftrf grthhtvghrnhephfeggfffjeffkeekudfgleffteegjeeftdejieehgedvhfdvfeeikeet hfefvdfhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epkhgrlhhoihgrnhesughoghgrnhhovhdrohhrghdpnhgspghrtghpthhtohepiedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtoheprghlrghnsehiughiohgthidrohhrghdprh gtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeihrghvohhrsehgnhhu rdhorhhgpdhrtghpthhtohepkhgrlhhoihgrnhesughoghgrnhhovhdrohhrghdprhgtph htthhopeektdduuddvseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepshhh ihhpmhhinhhtshesghhmrghilhdrtghomh X-ME-Proxy: <xmx:L0ldaSySOpSK03yom8JR7q3U5guDYl-GxIxX37aJ4x6PZs8XAxGzGw> <xmx:L0ldafCTSQs-upt4qXrA1JTv5rZTYuNuhwxiVyoE8iXVwi6fOPNpqg> <xmx:L0ldaQe8rfnZsO3UBrn5c9bCoHElTwUvMJNQ8SWTkGmjU7MFVW-cuw> <xmx:L0ldaZnPY9zsnFoBvUaZ5VEH_7hPcMQ5YYeRlMnbB36Bbh5qVEkfKw> <xmx:MEldad37wa25wXKmFp0-4oMkY1PNM_4ozFIXCRHVTfHPADLnMQSSYa4L> Feedback-ID: i5c90432c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Jan 2026 12:41:02 -0500 (EST) Date: Tue, 06 Jan 2026 19:41:01 +0200 Message-ID: <87qzs2iqqa.wl-kaloian@HIDDEN> From: Kaloian Doganov <kaloian@HIDDEN> To: Alan Third <alan@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, yavor@HIDDEN, kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <aV1DJhy23VSC7kbs@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <aV1DJhy23VSC7kbs@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80112 X-Mailman-Approved-At: Wed, 07 Jan 2026 03:36:52 -0500 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Tue, 06 Jan 2026 19:15:18 +0200, Alan Third wrote: > > On Tue, Jan 06, 2026 at 02:54:32PM +0200, Eli Zaretskii wrote: > > > Date: Mon, 5 Jan 2026 23:16:17 +0000 > > > From: Alan Third <alan@HIDDEN> > > > > > > Is it possible that pselect with those arguments is acting as a no-op > > > and the main thread is just blasting right through without ever > > > yielding to another thread? > > > > I was looking at this exact code and asking myself why does the main > > thread ignore the timeout argument and always calls thread_select with > > a zero timeout? What is the purpose of overriding the timeout (which > > comes from wait_reading_process_output), which is peculiar to the NS > > code? > > IIRC, this call is there purely to give other threads the chance to > run, the real pselect call is in the fd_handler thread. I don't know > if there's a better way to handle this so that other threads can run > while the main thread runs the NS runloop or whatever. On Eli's question about the timeout being zero, I would guess the intention was not to block the main thread, which could render the UI sluggish and non-responsive. So if I can summarize my understanding so far, ns_select makes this particular thread_select call purely to release the global lock for a bit and give other threads the chance to progress. It uses zero timeout so that if there's no other thread to take the global lock (a common case), the main thread would continue unimpeded without blocking the UI. But while that small opportunity is mostly enough on macOS, it seems too small for GNU/Linux. That could be because either glibc or Linux treat this pselect call as a an effective no-op.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 22:21:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 17:21:50 2026
Received: from localhost ([127.0.0.1]:60822 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdFR0-0006lT-CC
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 17:21:50 -0500
Received: from dane.soverin.net ([185.233.34.24]:45355)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vdFQx-0006l9-Qx
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 17:21:48 -0500
Received: from smtp.soverin.net (unknown [10.10.4.99])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by dane.soverin.net (Postfix) with ESMTPS id 4dm5HT4LM1zdR;
Tue, 06 Jan 2026 22:21:41 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net
(Postfix) with ESMTPSA id 4dm5HT1bRxz6w;
Tue, 6 Jan 2026 22:21:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
t=1767738101; bh=9xe3UT590Ko0bC5LiIBAZnEiw5/1cDQt9TLM+xOImKY=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=HRBwGifknM6pCwsaH0QZ+CnIOmm0w3AJ8pnLhk8vbHV8HCLLGluM7c+18SWwnuf9e
LS41OTdjbFEOuFHZpMIKiqBijDDQaL35kqSN92P/o2iIDATFBrrC2sUA5VYOztjQzG
cGDvPsLqTljs1tWdcLyUoONdcmKrJWNv3LzzLeNpgMKI0EZ5X1uyQV+38S5VCGbMrJ
v1x4IYYLhXD87kiOcwTeXDTvjtDX0L9iq90yjY7uA6QkGIXcdU45aIR2mxj9oGbkr8
tElz8BwkHDmj4FewDAhO06M1pSJ10KMKAvWegAYxvmA2RBOzjeTOxzbMdYItnAC5z2
+pEA7myRDdVBQ==
X-CM-Envelope: MS4xfJMM5kdOZoEyRJRd/FTBMifmHOu56zP0GjApAWTz+wBaSSSJ+LZT3lhR7KmIVozbITGzzBfwrm8eM7t31YpZbhAJaWfP1iK5M7kl8oWG+ZBBxuRaMuk3
ORyP7A1n9+ivAjEwWvuAMg5oT/wA+UwGxBb5OHIxETdenQqPE0FFH7cma8D8HbI9dg1EHCyUpn6v6kH6DRt+Wwy6wQwUvHqzytTSSz3hBi8qOBjHcek67RmJ
oqG9zvD8G7D50sC6Jb0Cs/Ezfmg1w7iHy0tBS3SAL7rZySCZiWjY4FhDkCgW0zHGmMLpAlK7z8fOtg2hOZ+c/1/mx7Ejz8U6Iuzuy0sdJQs=
X-Soverin-Id: 019b9566-cd08-77ad-8501-b44dbc3cf69e
Received: from localhost (namib [local])
by namib (OpenSMTPD) with ESMTPA id ddbb77a9;
Tue, 6 Jan 2026 22:21:40 +0000 (UTC)
Date: Tue, 6 Jan 2026 22:21:40 +0000
From: Alan Third <alan@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
Message-ID: <aV2K9IfRz6DAQTNZ@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
Yavor Doganov <yavor@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
References: <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN>
<86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN>
<86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN>
<86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN>
<86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN>
X-Spampanel-Class: ham
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 80112
Cc: Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
On Tue, Jan 06, 2026 at 09:31:51PM +0200, Yavor Doganov wrote:
> Eli Zaretskii wrote:
> > > Yes, I confirm that setting it to {0, 1} is enough to fix the
> > > problem
> >
> > Thanks.
> >
> > Does this also fix bug#80110, fingers crossed?
>
> No, as I said earlier in this discussion (when I mentioned that
> defining release_select_lock to sleep fixes the bug), when Lisp
> threads are working it is extremely easy to reproduce the freeze.
>
> The patch I proposed at #80110 fixes it, and perhaps the change should
> be made for both NS implementations. If so, it should be merged with
> the (NSApp == nil) condition as was in Adrian Robert's original code:
>
> if (NSApp == nil
> || ![NSThread isMainThread]
> || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> return thread_select (pselect, nfds, readfds, writefds,
> exceptfds, timeout, sigmask);
I think we need to remove the test of whether the timeout is zero,
because even if the timeout is zero we still need the NS runloop to
run.
--
Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 20:27:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 15:27:30 2026
Received: from localhost ([127.0.0.1]:59694 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdDeL-0000Mw-Ao
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 15:27:29 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37588)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vdDeI-0000MZ-9Q
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 15:27:27 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vdDeC-0005ZS-Dg; Tue, 06 Jan 2026 15:27:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=FhYWyUUwYEh/jxuBmEiFigbCIsSEToHZKdSAd+6dLaI=; b=NEGqkWH1tG0n
n5VI1G/WoFPhXNEYSbSnifHwQeL77yPbSlZ+C+QqvfnBxDH9nGVvw8DJzv2axgB19A/MoonW9oCSi
B9caYQZkO5cA7hf64/fvYGZmCiw6uy2SsboQ3BsMxNCf3caATpfapyxcm+pGXeK8hDzyjn6ZfNbtB
36vUarSTJF2Cj1Q4YZakhg20pYQ6fEvvEPbqmzyddeNaz/ci9tCWeCJpfyNMej+zAX1g8r35HfaVi
CPWQHaNSsEHNzRiTttEheq1ObeWxlHom+N//bEUzxhmyFfN9m1Pyc6swZSSVxKHOnrUwdysNcFMYA
Yv88bYpl5AT5b/TAbqXogg==;
Date: Tue, 06 Jan 2026 22:27:14 +0200
Message-Id: <864ioyebbx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
In-Reply-To: <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor
Doganov on Tue, 06 Jan 2026 21:31:51 +0200)
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
<87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN>
<86a4yqek8v.fsf@HIDDEN> <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: alan@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Tue, 06 Jan 2026 21:31:51 +0200
> From: Yavor Doganov <yavor@HIDDEN>
> Cc: Yavor Doganov <yavor@HIDDEN>,
> alan@HIDDEN,
> kaloian@HIDDEN,
> 80112 <at> debbugs.gnu.org,
> shipmints@HIDDEN
>
> Eli Zaretskii wrote:
> > > Yes, I confirm that setting it to {0, 1} is enough to fix the
> > > problem
> >
> > Thanks.
> >
> > Does this also fix bug#80110, fingers crossed?
>
> No, as I said earlier in this discussion (when I mentioned that
> defining release_select_lock to sleep fixes the bug), when Lisp
> threads are working it is extremely easy to reproduce the freeze.
>
> The patch I proposed at #80110 fixes it, and perhaps the change should
> be made for both NS implementations. If so, it should be merged with
> the (NSApp == nil) condition as was in Adrian Robert's original code:
>
> if (NSApp == nil
> || ![NSThread isMainThread]
> || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> return thread_select (pselect, nfds, readfds, writefds,
> exceptfds, timeout, sigmask);
So I guess we install both changes?
But please be sure to run test/src/thread-tests.el,
test/lisp/thread-tests.el, and test/src/process-tests.el from the test
suite, after applying both changes, and see if any of these tests fail
in some weird manner.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 20:24:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 15:24:23 2026 Received: from localhost ([127.0.0.1]:59686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdDbL-0000Bo-Fx for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 15:24:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43214) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vdDbG-0000BY-P2 for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 15:24:22 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vdDbA-00058I-HH; Tue, 06 Jan 2026 15:24:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cQZ16GaOdYjNbqzJPSPbsMt7MCtjqJFU8WMkMQ7pnwM=; b=Q5wGes4qMPSk 7B9lyFR/NgwHZtExizPTmpU9C0DaijZDIKHVCQearyAJGox6oeol84ujFe6pBgbOgN7rpTJ4mxB7h 6GlQbvhrQ38ILHAKiyDxfvCFfPiEfDeV63fillAYdtgMH38fZ/5LPU3i6rPsIzYfaXzqlTsRgHCwn rq2mxY1FLfGtTsMajwTLzpkZs7QNdSwKr5VbgtU2QyM8y01ab0TzoZQ5qqHy1LfrBQ1Nqqc1wZtCk Q7nHlNSvKfEV7f7LNl6b96dl4BlwvUlx3Cacleuhy1XPOnkUctTSPWCSHoRROUj1SY9XksI8HqBnk 3cfzRX7D03ktoRqrPmZwCA==; Date: Tue, 06 Jan 2026 22:24:08 +0200 Message-Id: <865x9eebh3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Kaloian Doganov <kaloian@HIDDEN> In-Reply-To: <87qzs2iqqa.wl-kaloian@HIDDEN> (message from Kaloian Doganov on Tue, 06 Jan 2026 19:41:01 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <aV1DJhy23VSC7kbs@HIDDEN> <87qzs2iqqa.wl-kaloian@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: alan@HIDDEN, 80112 <at> debbugs.gnu.org, yavor@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 06 Jan 2026 19:41:01 +0200 > From: Kaloian Doganov <kaloian@HIDDEN> > > On Eli's question about the timeout being zero, I would guess the intention was > not to block the main thread, which could render the UI sluggish and > non-responsive. > > So if I can summarize my understanding so far, ns_select makes this particular > thread_select call purely to release the global lock for a bit and give other > threads the chance to progress. It uses zero timeout so that if there's no > other thread to take the global lock (a common case), the main thread would > continue unimpeded without blocking the UI. There's no reason to use the zero timeout there. Emacs uses non-zero timeouts in its call to thread_select all the time, in its main loop, and it doesn't make Emacs non-responsive, because if there is some input available, pselect returns very quickly. If you drill down the call to read_char, which is what Emacs does when it needs to check whether there is any new input, you will see that it eventually calls thread_select, usually with a non-zero timeout. So if the responsiveness was the reason to use a zero timeout here, there shouldn't be a problem for us to use a small non-zero timeout, especially if that fixes bugs with thread scheduling.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 19:32:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 14:32:19 2026
Received: from localhost ([127.0.0.1]:59611 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdCmw-0006OV-N0
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 14:32:18 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:46420)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdCmt-0006OD-Qd
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 14:32:16 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>)
id 1vdCmn-0006yf-Ud; Tue, 06 Jan 2026 14:32:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From:
Date; bh=U2qxkP/EKlLxX5PTNNiUZtdzadrAILyCcYEAJucSWq0=; b=O4FIiJydRh8VXCGIYFOW
QejwYxibUD4QpOmMNtcm55wHGe0Bte4oRXd+CDJi9cWls/I3T1JhPf7UCe1ztpRq/O+1FC1Mzk4Ox
4FKI39vS6IB/xmD9k/yXcL5iBPcitLx1QHp1l0ErYbF1cPD1lN061qevjaPA6DHkOIuOAe0KL9EpU
RoA4FhKHJJ88Ji0085KnEldt6fQB8GBGLzMuJchjFN3icNSMBa3Ct6XFVnB7DdBL9MVoblZmIkn7Z
FUAfZDFl6fmEsAFiPp32xaAmlZSHI/UILdm2YKkm/AgbfOVhcDpNggIqc4i3CqVaXzgYrXjLNYA2d
g7f8vNhkBDVCCA==;
Date: Tue, 06 Jan 2026 21:31:51 +0200
Message-ID: <87jyxutu54.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
In-Reply-To: <86a4yqek8v.fsf@HIDDEN>
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
<87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> <86a4yqek8v.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org,
alan@HIDDEN, shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Eli Zaretskii wrote:
> > Yes, I confirm that setting it to {0, 1} is enough to fix the
> > problem
>
> Thanks.
>
> Does this also fix bug#80110, fingers crossed?
No, as I said earlier in this discussion (when I mentioned that
defining release_select_lock to sleep fixes the bug), when Lisp
threads are working it is extremely easy to reproduce the freeze.
The patch I proposed at #80110 fixes it, and perhaps the change should
be made for both NS implementations. If so, it should be merged with
the (NSApp == nil) condition as was in Adrian Robert's original code:
if (NSApp == nil
|| ![NSThread isMainThread]
|| (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
return thread_select (pselect, nfds, readfds, writefds,
exceptfds, timeout, sigmask);
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 19:12:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 14:12:19 2026 Received: from localhost ([127.0.0.1]:59588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdCTa-0005VI-Ko for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 14:12:18 -0500 Received: from dane.soverin.net ([185.233.34.150]:52331) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vdCTY-0005V3-E9 for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 14:12:17 -0500 Received: from smtp.soverin.net (unknown [10.10.4.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4dm14n50ssz5h; Tue, 06 Jan 2026 19:12:09 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4dm14n1MvszLm; Tue, 6 Jan 2026 19:12:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1767726729; bh=2PffpVG/x3/dDGElZ9NgzP0bqva4k79ovjlXxqx41UM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GA7hNAgwJ03o290k4sSNlFF+JUfuDJv+G3C0VBz9VXcZ9XCj4jBraLJ5bIKL275JS ZwIqqAhFig6DhmzFAyS86LDwBxwe0aD6qpqe/eNXzVmvScbYW/tUE7I59vZn+kgNFj alAxdElck0FgZquN3XvOeZeD8akfKunSTSbHbg8Qvo1vwMq4w4a3UqApXjUkVKNceA 1KkSWz2o+NuQ0ibgPJEx5I3J1KMkgQ9I3PTzeU9PNbsQ6NnQAPY3/c2WF7QqNiSWi8 IIzLDkzkRPyfo2wkaOshNP4ikTmdO0RJaauxfwwEYBP1a5b6yKAHVSvAOT+n85qJT/ mPFqgBXelFkUg== X-CM-Envelope: MS4xfCKKGG7kQn1w+gK1Mq/gC9fhcHQ7bWYt4L53Ox/FmvF8EJuUhtGsQ8VCxp8TxKn/GW6SBxwFFTxBQKCJSCodEjIjl04PYp2JJC+C7k0qyCZJGmMJ+gEH S1/2nGpfhOeDGqctgHl8MtkYeqF9VkeSBcjYxY14Xtu7VVz+nO6OJVAqErrhPPENtSiC1gbzH96OBd0OXLXWh49HLXrlisYGjMa6lmwQh3pUQ0nLHR8o3n36 XmdswrSxlqDCcajexlOoHJdYv8VMUnvDk3JPkfOeZZx2da0NrYAWzXUk2f2+7bWRxzxsHcuNJ2HjKSvXxzErqQ== X-Soverin-Id: 019b94b9-4728-7e11-9316-45ccc1538ea7 Received: from localhost (faroe.holly.idiocy.org [local]) by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id 235da4d5; Tue, 6 Jan 2026 19:12:08 +0000 (UTC) Date: Tue, 6 Jan 2026 19:12:08 +0000 From: Alan Third <alan@HIDDEN> To: Kaloian Doganov <kaloian@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it Message-ID: <aV1eiNCzuL_FHWrA@HIDDEN> Mail-Followup-To: Alan Third <alan@HIDDEN>, Kaloian Doganov <kaloian@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, yavor@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN> <aV1DJhy23VSC7kbs@HIDDEN> <87qzs2iqqa.wl-kaloian@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87qzs2iqqa.wl-kaloian@HIDDEN> X-Spampanel-Class: ham X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80112 Cc: Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org, yavor@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Tue, Jan 06, 2026 at 07:41:01PM +0200, Kaloian Doganov wrote: > On Tue, 06 Jan 2026 19:15:18 +0200, > Alan Third wrote: > > > > On Tue, Jan 06, 2026 at 02:54:32PM +0200, Eli Zaretskii wrote: > > > > Date: Mon, 5 Jan 2026 23:16:17 +0000 > > > > From: Alan Third <alan@HIDDEN> > > > > > > > > Is it possible that pselect with those arguments is acting as a no-op > > > > and the main thread is just blasting right through without ever > > > > yielding to another thread? > > > > > > I was looking at this exact code and asking myself why does the main > > > thread ignore the timeout argument and always calls thread_select with > > > a zero timeout? What is the purpose of overriding the timeout (which > > > comes from wait_reading_process_output), which is peculiar to the NS > > > code? > > > > IIRC, this call is there purely to give other threads the chance to > > run, the real pselect call is in the fd_handler thread. I don't know > > if there's a better way to handle this so that other threads can run > > while the main thread runs the NS runloop or whatever. > > On Eli's question about the timeout being zero, I would guess the intention was > not to block the main thread, which could render the UI sluggish and > non-responsive. > > So if I can summarize my understanding so far, ns_select makes this particular > thread_select call purely to release the global lock for a bit and give other > threads the chance to progress. It uses zero timeout so that if there's no > other thread to take the global lock (a common case), the main thread would > continue unimpeded without blocking the UI. But while that small opportunity is > mostly enough on macOS, it seems too small for GNU/Linux. That could be because > either glibc or Linux treat this pselect call as a an effective no-op. This is my understanding. -- Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 19:04:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 14:04:17 2026
Received: from localhost ([127.0.0.1]:59557 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdCLp-000546-1D
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 14:04:17 -0500
Received: from dane.soverin.net ([185.233.34.149]:59557)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vdCLm-00053o-KM
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 14:04:15 -0500
Received: from smtp.soverin.net (unknown [10.10.4.99])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by dane.soverin.net (Postfix) with ESMTPS id 4dm0vW6zCmzjB;
Tue, 06 Jan 2026 19:04:07 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net
(Postfix) with ESMTPSA id 4dm0vW3gXyz6w;
Tue, 6 Jan 2026 19:04:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
t=1767726247; bh=axwAfZkxD0xZEuNebi8x807h/HZbyPa5ClAGKZmfft0=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=LfyFBzyQoBZwr8Rgg8nEyrrYOq3ChlyFThvjXfaXwqL3+Pp13ZPWCdncHEY5so776
bvKMBT3MJPq246SRzjH4R7Nzkj0rDNdi7hTdk3IEzXwN3kx8l+ce1eXXRh60FWmirk
OrV6HpXT9EMrBTN8dX3PFfopv/vnmt548HVkSXkWo0T64sK9AHm/N5wT1/lCT3Au4F
M3ho3qTb2o+U/xe6GkVjlrwrZkI/Rp9MB53ylKk2rHODeBRaB0AGWRB30MmqyWdseV
2wtX1twzOFOQnF7SNJwmfIQZk7j6oEifb3F7hhsLZL8JGld6tCz81KfPcxr41Bb++j
1oxhHbn7z2YxA==
X-CM-Envelope: MS4xfCjeZ7nuINPS/nBuA5yliezVNe0pcinAOghD8DzcKYYkrVLPOWLVzCiTdIbSqrlcAl2yF+H56rTl4FcpSlgAZVlzMHWnLV0d7YrVB5K/4qFksId4u3qR
IVW+UrggQk4Y3vY9t8Q3Dv2Zw3c967BpWSjhB+L2BsDzArZUd4hDeyA+HW3Lk2o1RhwlWXh1T/yOslnBmVFEz/U3qINmP1b9FAlVCn4uzUamSY5g0BzcRhOE
sApQ+PPlRZs3Y15vkdLC2H9uqFnm83zAc7/sWI9f5SmbOub4ehopuRPxhYoIUysXv9+Cz4NHcRN8uaRCbALgFg==
X-Soverin-Id: 019b94b1-ec58-71e4-a5df-1eacbf9e1129
Received: from localhost (faroe.holly.idiocy.org [local])
by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id 29d0887b;
Tue, 6 Jan 2026 19:04:06 +0000 (UTC)
Date: Tue, 6 Jan 2026 19:04:06 +0000
From: Alan Third <alan@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
Message-ID: <aV1cpm5TUC1mBZC5@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, yavor@HIDDEN, kaloian@HIDDEN,
80112 <at> debbugs.gnu.org, shipmints@HIDDEN
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
<aV1DJhy23VSC7kbs@HIDDEN> <868qeaejsh.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <868qeaejsh.fsf@HIDDEN>
X-Spampanel-Class: ham
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 80112
Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
On Tue, Jan 06, 2026 at 07:24:30PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 6 Jan 2026 17:15:18 +0000
> > From: Alan Third <alan@HIDDEN>
> > Cc: yavor@HIDDEN, kaloian@HIDDEN, 80112 <at> debbugs.gnu.org,
> > shipmints@HIDDEN
> >
> > > I was looking at this exact code and asking myself why does the main
> > > thread ignore the timeout argument and always calls thread_select with
> > > a zero timeout? What is the purpose of overriding the timeout (which
> > > comes from wait_reading_process_output), which is peculiar to the NS
> > > code?
> >
> > IIRC, this call is there purely to give other threads the chance to
> > run, the real pselect call is in the fd_handler thread. I don't know
> > if there's a better way to handle this so that other threads can run
> > while the main thread runs the NS runloop or whatever.
>
> If that's the reason, then {0, 1} should be also good enough, don't
> you agree?
I think so.
> Moreover, it could be better, because it avoids the potential
> problem of "optimizing" zero-wait pselect calls which deny other
> threads an opportunity to grab the global lock.
>
> Btw, does the recipe of this bug work as expected on macOS? If yes,
> then the change of the timeout to a small but nonzero one should be
> limited to GNUstep on GNU/Linux, to avoid unintended consequences in
> this tricky area.
I'll see if I can test it later. But I do wonder if this is the source
of some of the freezes Gerd reported on macOS.
> And I wonder: wait_reading_process_output calls thread_select (via
> ns_select in the NS case) with a non-zero timeout, and does that for a
> reason. Are you saying that in the NS port that timeout is used in
> "the real pselect in the fd_handler thread" instead? Because if that
> timeout is entirely ignored by the NS build and not obeyed anywhere,
> that is not a very good situation, I think.
The timeout is used correctly by fd_handler. If there are no file
descriptors the NS runloop is set to return after this time instead of
using fd_handler, so in either case the timeout is used.
--
Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 17:24:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 12:24:47 2026
Received: from localhost ([127.0.0.1]:59301 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdAnW-0000CZ-N5
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:24:47 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:45972)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vdAnT-0000Bk-OW
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:24:44 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vdAnO-0004bR-2j; Tue, 06 Jan 2026 12:24:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=+VmcKG9uYFrc096vEh61nUoJUWpjRL4Vtdj/5URyOog=; b=CZo+i9ck7Ack
wlhJVbt7RKQYRMwtn22wRqISgPfaVWD3mGYOYqwrM2SBWqAnmdYXBw07CQ8zI2+r4DYeWAu+zq2OG
KqKynh4eYgVJ7i/XJXzaJYIymXvMJ+5eRM8bsczkxLp8/dp4cZdOhofFHRWaGXDj5CZAaZZ14LLlG
CYqs7RFuPLHyKIrugyipkFNF+Qs39tTzyp8MIb2wrHsYyv8vy6fmIJF2KS+zpcblTpWJEcMtSnyTa
dZktRkfEnu0jNByMmw5bjcqj44cKgJCbZn61Qrictyd2+neocFuVN1MNkYaXJOFp8diX3xnpot1gT
tQIjMdd8pHZBz5pCN21tvA==;
Date: Tue, 06 Jan 2026 19:24:30 +0200
Message-Id: <868qeaejsh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Third <alan@HIDDEN>
In-Reply-To: <aV1DJhy23VSC7kbs@HIDDEN> (message from Alan
Third on Tue, 6 Jan 2026 17:15:18 +0000)
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN>
<86wm1uewaf.fsf@HIDDEN> <aV1DJhy23VSC7kbs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Tue, 6 Jan 2026 17:15:18 +0000
> From: Alan Third <alan@HIDDEN>
> Cc: yavor@HIDDEN, kaloian@HIDDEN, 80112 <at> debbugs.gnu.org,
> shipmints@HIDDEN
>
> > I was looking at this exact code and asking myself why does the main
> > thread ignore the timeout argument and always calls thread_select with
> > a zero timeout? What is the purpose of overriding the timeout (which
> > comes from wait_reading_process_output), which is peculiar to the NS
> > code?
>
> IIRC, this call is there purely to give other threads the chance to
> run, the real pselect call is in the fd_handler thread. I don't know
> if there's a better way to handle this so that other threads can run
> while the main thread runs the NS runloop or whatever.
If that's the reason, then {0, 1} should be also good enough, don't
you agree? Moreover, it could be better, because it avoids the
potential problem of "optimizing" zero-wait pselect calls which deny
other threads an opportunity to grab the global lock.
Btw, does the recipe of this bug work as expected on macOS? If yes,
then the change of the timeout to a small but nonzero one should be
limited to GNUstep on GNU/Linux, to avoid unintended consequences in
this tricky area.
And I wonder: wait_reading_process_output calls thread_select (via
ns_select in the NS case) with a non-zero timeout, and does that for a
reason. Are you saying that in the NS port that timeout is used in
"the real pselect in the fd_handler thread" instead? Because if that
timeout is entirely ignored by the NS build and not obeyed anywhere,
that is not a very good situation, I think.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 17:22:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 12:22:45 2026 Received: from localhost ([127.0.0.1]:59266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vdAlY-00006j-VL for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:22:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54066) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdAlW-00006Q-6x for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:22:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vdAlQ-0004Kx-CZ; Tue, 06 Jan 2026 12:22:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=3b2qVJzjjGu3MIralZGcSIpntBkHw1pdzQ0B5038KwU=; b=GwSsRwsX5QrSLhySzYIP Dfo4DXzeOhOL7RGjG39K5r0bxs+pXxrKHuWxlMAdO3cWGnna5mCvLnpyDY9NxLsfmyrPejtWQYSoL V/NijnHtZJOAUiPrPk2hb+fz9uzJM6TzDnSE4T52T6ygY6x2QGkrf3SbaMriK7xkdZ55pnkjzerkt Fb3uXj/5kh5/ZCjmyVIxtDaLnR7Svj1Y/EXJ7TkJTf0ig5BcEwVlXBhxDUisJEPzC0IzKB4OyYUxW A4McjsJ2UAeWigtSdA+XIDKM0+GPgHvwHMg+LTkHicwWeK4WAGqXISs/uU1/3N5rzyMbMG1K7pa72 DnLWLGPSM6hJ0Q==; Date: Tue, 06 Jan 2026 19:22:20 +0200 Message-ID: <87y0mafygj.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <861pk2gbt4.fsf@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> <87v7hjhug1.wl-kaloian@HIDDEN> <86jyxykex0.fsf@HIDDEN> <87tsx2iiwt.wl-kaloian@HIDDEN> <86ms2uighy.fsf@HIDDEN> <87secjiz2h.wl-kaloian@HIDDEN> <861pk2gbt4.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: Kaloian Doganov <kaloian@HIDDEN>, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN, yavor@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii wrote: > > From: Kaloian Doganov <kaloian@HIDDEN> > > AFAIK, the NS world (being GNUstep or Apple Foundation) doesn't > > suspect this thread exists at all. It is a POSIX thread, which > > just runs unencumbered by the NS world and outside of its control. > > All of the threads involved in this are POSIX threads. It's just that > some of them can run Lisp and execute parts of the Emacs Lisp machine, > and others don't. And only those who can run Lisp attempt to take the > global lock before they run Lisp. Of course they are. Kaloian was talking about the GNUstep/FoundationKit threading system. In a GNUstep application, you are supposed to use NSThread methods to create new threads, so that notifications are posted when the program becomes multi-threaded, etc. You can also add observers and watch when a thread exits or do some other things that are sometimes useful. This mechanism is used for thread locking and synchronization. GNUstep provides GSRegisterCurrentThread (and a matching unregister function) that wraps a thread created by other means (pthread_create) in an NSThread object and keeps track of it. A few days ago when I was much more desperate than now, I tried to use these functions to register/unregister the Lisp threads. It worked but it didn't make any difference.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 17:15:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 12:15:30 2026
Received: from localhost ([127.0.0.1]:59230 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdAeX-0008B1-J0
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:15:30 -0500
Received: from dane.soverin.net ([185.233.34.38]:33163)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vdAeU-00087y-3w
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:15:27 -0500
Received: from smtp.soverin.net (unknown [10.10.4.100])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by dane.soverin.net (Postfix) with ESMTPS id 4dlyTz3fzxz1dPS;
Tue, 06 Jan 2026 17:15:19 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by
soverin.net (Postfix) with ESMTPSA id 4dlyTy5tpszLm;
Tue, 6 Jan 2026 17:15:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
t=1767719719; bh=NI7aH5IQIfpWva1Z7iYm0PuM91J/0aaHBMuYG2Ny6G0=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=B7rqepnpMHGxEn4B9+D7egGuV4ev37a2TMBS3lqPbX/XgAFCs+Q2Zk7Grin7KbK8r
Lrx8barroaAwO8eDcdE6WxxzHZ2EwpXAEfGCT12p5D62taMmLM3jGpwA0nMHzQRXZQ
J5bf6LWjAp5WjhRRSRra2/2BVYNhTi+cK0F8H+eoueVAzn63mb7dAAKqXTeFSA9ryN
7C6vKVOImJ+vg+UenNGeJBiKCb/0ZgQepsGZUoEylbyoXkzyU81Hsb/S29xv8c83Ue
N0YaaqfI4ARBRjCPL28eqBqR7hgECx+U+LC1pgmhjD2mA9lkFcScqQHYEzuNSyqEHA
sYPeKX6iqiXrg==
X-CM-Envelope: MS4xfC8af/qxgxwTD0MSwIXfJx26VaPzFj9gsepjz0QSsnmguA+IJzfttHVITiIU+jE7bvDjKdZraNwVfvAK5F99FHyf+goqYAqA3O2mhh5kDmdvhck/Oc8l
3HoGkDM5yYd03Gnz23+HQL67DmAj8PWVOjWKiSWOQri2l9VtkkZt1AoEkdkTBUNsSYX2+HQWTGRlAYRfOukf/b6pXm8SPwUzh9S4vpYngSwX+qShP3O7pP+L
A00m/I3fDoviUTl0DDt9sQ/7lfNcFS35r6rFEaMj2TqRvxzXZr/DgWUNeWdhGrw/Jg7sDynA4iwvu4DFMDNOyg==
X-Soverin-Id: 019b944e-5058-7ae6-baed-85ad6ae66a01
Received: from localhost (faroe.holly.idiocy.org [local])
by faroe.holly.idiocy.org (OpenSMTPD) with ESMTPA id ca7ec38b;
Tue, 6 Jan 2026 17:15:18 +0000 (UTC)
Date: Tue, 6 Jan 2026 17:15:18 +0000
From: Alan Third <alan@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
Message-ID: <aV1DJhy23VSC7kbs@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, yavor@HIDDEN, kaloian@HIDDEN,
80112 <at> debbugs.gnu.org, shipmints@HIDDEN
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86wm1uewaf.fsf@HIDDEN>
X-Spampanel-Class: ham
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80112
Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On Tue, Jan 06, 2026 at 02:54:32PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 5 Jan 2026 23:16:17 +0000
> > From: Alan Third <alan@HIDDEN>
> > Cc: Yavor Doganov <yavor@HIDDEN>, kaloian@HIDDEN,
> > 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
> >
> > On Mon, Jan 05, 2026 at 04:05:13PM +0200, Eli Zaretskii wrote:
> > > static void
> > > really_call_select (void *arg)
> > > {
> > > struct select_args *sa = arg;
> > > struct thread_state *self = current_thread;
> > > sigset_t oldset;
> > >
> > > block_interrupt_signal (&oldset);
> > > self->not_holding_lock = 1;
> > > release_global_lock (); <<<<<<<<<<<<<< (1)
> > > restore_signal_mask (&oldset);
> > >
> > > sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds,
> > > sa->timeout, sa->sigmask); <<<<<<<<<<<<<< (2)
> > >
> > > release_select_lock ();
> > >
> > > block_interrupt_signal (&oldset);
> > > /* If we were interrupted by C-g while inside sa->func above, the
> > > signal handler could have called maybe_reacquire_global_lock, in
> > > which case we are already holding the lock and shouldn't try
> > > taking it again, or else we will hang forever. */
> > > if (self->not_holding_lock)
> > > {
> > > acquire_global_lock (self); <<<<<<<<<<<<<< (3)
> > > self->not_holding_lock = 0;
> > > }
> > > restore_signal_mask (&oldset);
> > > }
> > >
> > > As you can see, it (1) releases the global lock, (2) calls sa->func
> > > (which should be pselect in your case), and only then (3) attempts to
> > > re-acquire the global lock. So how can it "immediately acquire back"
> > > the lock, bypassing the call to pselect??
> >
> > Sorry, this is probably a really stupid question, but the NS main
> > thread calls pselect like this:
> >
> > struct timespec t = {0, 0};
> > thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
> >
> > Is it possible that pselect with those arguments is acting as a no-op
> > and the main thread is just blasting right through without ever
> > yielding to another thread?
>
> I was looking at this exact code and asking myself why does the main
> thread ignore the timeout argument and always calls thread_select with
> a zero timeout? What is the purpose of overriding the timeout (which
> comes from wait_reading_process_output), which is peculiar to the NS
> code?
IIRC, this call is there purely to give other threads the chance to
run, the real pselect call is in the fd_handler thread. I don't know
if there's a better way to handle this so that other threads can run
while the main thread runs the NS runloop or whatever.
--
Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 17:15:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 12:15:03 2026
Received: from localhost ([127.0.0.1]:59224 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdAe6-00087J-2y
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:15:02 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37614)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vdAe3-00086d-N7
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:15:00 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vdAdv-0007xi-PG; Tue, 06 Jan 2026 12:14:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=bbBhKXZm3uiy+zI1NOLOvMdFkcoB6f86sOVZNe5Sdxo=; b=OR2+ZdVG2Wo9
YXgUlNxRYqI+vbFuOZa0dkWkTugand5SeoFrVpSQek141USbahjWqhERpJois8AL4uWzv2xwkQepy
hRCUv3c8fz38ShrNKD4La0xe3lBEnz6a/QAMdS01fmIHQm92huzu3R656pTXc+dBLVDiLzfMpR95t
pvU4mVryuqcX7VwkpZDj6B/ORVWyGXrg+OGLzH7YRkEZYaoC2af6Voym2d3L1P/IbDZdUXL7j/LiC
TExysGxUrutYQ1ofILRES98v5XIdm2Dhh8I505feeI25wk4Y/WHDGxMge+V5rb+VhQUB8J8kIlFA1
sVGbuxdNBHjePLmvyAZ+8w==;
Date: Tue, 06 Jan 2026 19:14:40 +0200
Message-Id: <86a4yqek8v.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
In-Reply-To: <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor
Doganov on Tue, 06 Jan 2026 19:00:56 +0200)
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN>
<86wm1uewaf.fsf@HIDDEN> <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: alan@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Tue, 06 Jan 2026 19:00:56 +0200
> From: Yavor Doganov <yavor@HIDDEN>
> Cc: Alan Third <alan@HIDDEN>,
> yavor@HIDDEN,
> kaloian@HIDDEN,
> 80112 <at> debbugs.gnu.org,
> shipmints@HIDDEN
>
> Eli Zaretskii wrote:
> > > From: Alan Third <alan@HIDDEN>
> > > Sorry, this is probably a really stupid question, but the NS main
> > > thread calls pselect like this:
> > >
> > > struct timespec t = {0, 0};
> > > thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
> > >
> > > Is it possible that pselect with those arguments is acting as a no-op
> > > and the main thread is just blasting right through without ever
> > > yielding to another thread?
> >
> > I was looking at this exact code and asking myself why does the main
> > thread ignore the timeout argument and always calls thread_select with
> > a zero timeout? What is the purpose of overriding the timeout (which
> > comes from wait_reading_process_output), which is peculiar to the NS
> > code?
>
> This code was added by Alan in commit 0ad5fd4 (July 2017) to fix
> Bug#25265 (the very same bug I already mentioned). I also don't
> understand why it is there but I don't understand many things...
Then hopefully Alan will be able to explain the reasons. Alan?
> > Yavor, if you replace the zero timeout in nsterm.m's call to
> > thread_select shown above with a very small, but non-zero timeout,
> > does the problem go away, per chance?
>
> Yes, I confirm that setting it to {0, 1} is enough to fix the problem
> (with the sa->timeout modification you asked me to do in
> really_call_select reverted).
Thanks.
Does this also fix bug#80110, fingers crossed?
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 17:01:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 12:01:28 2026
Received: from localhost ([127.0.0.1]:59182 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vdAQx-0007Yr-A8
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:01:27 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:60192)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vdAQu-0007YX-GC
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 12:01:25 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>)
id 1vdAQo-0005Kb-8W; Tue, 06 Jan 2026 12:01:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From:
Date; bh=7nD7vEPvtUkrg4sp0IhOnSDg1h/Gxk6e6kLHKQjrEG4=; b=gP74chTto8U/wJ3iNqW9
ovbS4Qr/hY1kEvyCRgQdtnLNI34iV4ifBAFlo3buXbppkBuWjbhpAAqBJJgv2F7hsB69KW0cVoGh2
9YbhZQuycmcCLnvW0rpZL8FUecS/hWYrhefIOkwpUqhVJQhSKyoh5bJyJQ+nLQbu1iU+hko8HLN2Y
NlFSjLyPSinvC/gaxAAHjDwtzdDGpgXO0TYm2uPMdDnisBpPtRz5ShKd49hMaVMfsU/MqsbYaV7+i
MR/rylOEgZLgxkxsmbOgye+evZbp7bPrtTNzPUSxMNWa+GrM4w2as5Fid13tZYn3TY4l0+H5lTmmE
dIMO4IyJvTj5cA==;
Date: Tue, 06 Jan 2026 19:00:56 +0200
Message-ID: <87zf6qfzg7.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
In-Reply-To: <86wm1uewaf.fsf@HIDDEN>
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<aVxGQZycMEKv484Y@HIDDEN> <86wm1uewaf.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, Alan Third <alan@HIDDEN>, 80112 <at> debbugs.gnu.org,
yavor@HIDDEN, shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Eli Zaretskii wrote:
> > From: Alan Third <alan@HIDDEN>
> > Sorry, this is probably a really stupid question, but the NS main
> > thread calls pselect like this:
> >
> > struct timespec t = {0, 0};
> > thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
> >
> > Is it possible that pselect with those arguments is acting as a no-op
> > and the main thread is just blasting right through without ever
> > yielding to another thread?
>
> I was looking at this exact code and asking myself why does the main
> thread ignore the timeout argument and always calls thread_select with
> a zero timeout? What is the purpose of overriding the timeout (which
> comes from wait_reading_process_output), which is peculiar to the NS
> code?
This code was added by Alan in commit 0ad5fd4 (July 2017) to fix
Bug#25265 (the very same bug I already mentioned). I also don't
understand why it is there but I don't understand many things...
> Yavor, if you replace the zero timeout in nsterm.m's call to
> thread_select shown above with a very small, but non-zero timeout,
> does the problem go away, per chance?
Yes, I confirm that setting it to {0, 1} is enough to fix the problem
(with the sa->timeout modification you asked me to do in
really_call_select reverted).
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 13:01:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 08:01:17 2026 Received: from localhost ([127.0.0.1]:57418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vd6gX-0003kC-99 for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 08:01:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47016) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vd6gU-0003jz-Ox for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 08:01:15 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vd6gM-0001Hb-LO; Tue, 06 Jan 2026 08:01:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=87eK6hqulNOHM/YoBGQHF2GYij0ca+bHWqCB3+3sufg=; b=Mghrw7eLsyME pcqWKJaSQsxy0qowEInD134bFVtfyx4cYhhCiMszJ/Lg+gJGK2eW5wK5ndX2+f+osowi9H9JjL8+v gS78kFmHwkxqZAK3cg8eTTJRlP3SCg6wQVpVhUj35ZT0jTqJ3eSv0PRP9TJRodRPT+YlA4Wt8CxGM LGxmHUAS4Lywp6ykIBeQcVozqJb56jJ1MOL/62bu3jk7wKmStPSthImTXWt10Bln52iwMMQPvg++u b7QeDQMBp4bTiJCBPRsif14dYV16NijhOqgBpUglO01HBdUw3yVwjU+4CJ9LiQSM3SreouO1PnRL8 JmjN1cdsAaiXQlRBw59Aug==; Date: Tue, 06 Jan 2026 15:00:57 +0200 Message-Id: <86tswyevzq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Alan Third <alan@HIDDEN> In-Reply-To: <aVxJ-04VWjdsNYiV@HIDDEN> (message from Alan Third on Mon, 5 Jan 2026 23:32:11 +0000) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdgf19m.fsf@HIDDEN> <87qzs34x1s.GNU's_not_UNIX!-yavor@HIDDEN> <aVxJ-04VWjdsNYiV@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 5 Jan 2026 23:32:11 +0000 > From: Alan Third <alan@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, kaloian@HIDDEN, > 80112 <at> debbugs.gnu.org, shipmints@HIDDEN > > > > I suspect that changing it to: > > > > > > if (![NSThread isMainThread]) > > > return thread_select (pselect, nfds, readfds, writefds, > > > exceptfds, timeout, sigmask); > > > else > > > ... > > > > > > would fix this and retain whatever behaviour Gerd was aiming for. > > > > This is basically the patch I proposed for Bug#80110. It fixes the > > freezes described there but not this bug. > > Ah, apologies, I didn't realise this was a different bug report. They seem to be related, though. If a simple test case with a single non-main thread doesn't work, something very fundamental is broken in how Lisp threads work on GNUstep.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 12:54:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 07:54:46 2026
Received: from localhost ([127.0.0.1]:57401 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vd6aD-0003Ls-HW
for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 07:54:45 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:41560)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vd6a9-0003LZ-Pw
for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 07:54:43 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vd6a3-0006WQ-Gb; Tue, 06 Jan 2026 07:54:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=pSn2JHkfFagx4aD+uMpdsb6y62U6t4hRJIIKqdOTk3Q=; b=XUS3XH5jxBRv
dRC1n/BrsZ5ZTxxEosbekv7x2JEpbsPu4qxRZvGrvPOoGWXef5TsfxfrCG8/4M4kMEiFEbw1Jvens
n0NxIZkT3nluJQIGILGXiwL4dYuwECN+XEy1dGTCNh/aVycgQWoeLXrEVTcVGxZ8k/Ib9/me5ZH8K
Mx6GD2B/+b53dJCuH5lLF88nCdyN+7Mz0jSQXz0GVZ2fomQ22hanlC8yyIG/Pri3pz8HE7DWk8DKJ
XxhehYpXVDM32melfBibdGKcMAdjL3m0rkbsfPiMCaq8sSSkQs04D+hhUYiFYiAvhgtjmGhQ5YSWX
HbVOJT34Vov3I7h8f0YVgg==;
Date: Tue, 06 Jan 2026 14:54:32 +0200
Message-Id: <86wm1uewaf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Third <alan@HIDDEN>
In-Reply-To: <aVxGQZycMEKv484Y@HIDDEN> (message from Alan
Third on Mon, 5 Jan 2026 23:16:17 +0000)
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN>
<86pl7of946.fsf@HIDDEN> <aVxGQZycMEKv484Y@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Mon, 5 Jan 2026 23:16:17 +0000
> From: Alan Third <alan@HIDDEN>
> Cc: Yavor Doganov <yavor@HIDDEN>, kaloian@HIDDEN,
> 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
>
> On Mon, Jan 05, 2026 at 04:05:13PM +0200, Eli Zaretskii wrote:
> > static void
> > really_call_select (void *arg)
> > {
> > struct select_args *sa = arg;
> > struct thread_state *self = current_thread;
> > sigset_t oldset;
> >
> > block_interrupt_signal (&oldset);
> > self->not_holding_lock = 1;
> > release_global_lock (); <<<<<<<<<<<<<< (1)
> > restore_signal_mask (&oldset);
> >
> > sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds,
> > sa->timeout, sa->sigmask); <<<<<<<<<<<<<< (2)
> >
> > release_select_lock ();
> >
> > block_interrupt_signal (&oldset);
> > /* If we were interrupted by C-g while inside sa->func above, the
> > signal handler could have called maybe_reacquire_global_lock, in
> > which case we are already holding the lock and shouldn't try
> > taking it again, or else we will hang forever. */
> > if (self->not_holding_lock)
> > {
> > acquire_global_lock (self); <<<<<<<<<<<<<< (3)
> > self->not_holding_lock = 0;
> > }
> > restore_signal_mask (&oldset);
> > }
> >
> > As you can see, it (1) releases the global lock, (2) calls sa->func
> > (which should be pselect in your case), and only then (3) attempts to
> > re-acquire the global lock. So how can it "immediately acquire back"
> > the lock, bypassing the call to pselect??
>
> Sorry, this is probably a really stupid question, but the NS main
> thread calls pselect like this:
>
> struct timespec t = {0, 0};
> thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
>
> Is it possible that pselect with those arguments is acting as a no-op
> and the main thread is just blasting right through without ever
> yielding to another thread?
I was looking at this exact code and asking myself why does the main
thread ignore the timeout argument and always calls thread_select with
a zero timeout? What is the purpose of overriding the timeout (which
comes from wait_reading_process_output), which is peculiar to the NS
code?
And yes, it's possible that there's some "optimization", whereby
zero-wait call to pselect is exempt from examination by the scheduler.
Yavor, if you replace the zero timeout in nsterm.m's call to
thread_select shown above with a very small, but non-zero timeout,
does the problem go away, per chance?
(I believe that a very small value there will actually let pselect
wait for something like 50 microseconds, due to the granularity of
that on GNU/Linux.)
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 12:34:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 07:34:46 2026 Received: from localhost ([127.0.0.1]:57325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vd6Gr-0002NR-KW for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 07:34:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58702) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vd6Gp-0002Ms-Cm for 80112 <at> debbugs.gnu.org; Tue, 06 Jan 2026 07:34:44 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vd6Gj-0007kd-Vw; Tue, 06 Jan 2026 07:34:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ce1xMGTepEGeTL7pSFBvQ0jVI6en+mKJtDLX6V8MqAw=; b=e0fwCzI4aQQ9 bewiUBXHTgt586ix1Fq/pb0dNkyJXI49he46OjTdBXiTEwTyTE+qmgy7J8x8R5urlr3Dzjwt8B88U Fn6DciRx36sf3zAcc1UdTRMf6PshgNCi+WBHvZrEG9d2Q8smc/0xbnNS0yF4UQRnK6hpyicrnmVgN /jC+WidyG1+uBrVkUjCKftGnp61L4TT6ijP4VQ2DqoohDbN/FfZt3RRori1MLgqnhUwEvcEOWvXUL 3Qtumftgu2poUkf8MhPbhmCBoo8xwbERICnA/gYyf28dV3XyFi+LQBweBiauV80SIsDxl8c1b4eqO l2JacsbqXCpb1+43Nrtnjg==; Date: Tue, 06 Jan 2026 14:33:59 +0200 Message-Id: <861pk2gbt4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Kaloian Doganov <kaloian@HIDDEN> In-Reply-To: <87secjiz2h.wl-kaloian@HIDDEN> (message from Kaloian Doganov on Mon, 05 Jan 2026 22:28:38 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> <87v7hjhug1.wl-kaloian@HIDDEN> <86jyxykex0.fsf@HIDDEN> <87tsx2iiwt.wl-kaloian@HIDDEN> <86ms2uighy.fsf@HIDDEN> <87secjiz2h.wl-kaloian@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 05 Jan 2026 22:28:38 +0200 > From: Kaloian Doganov <kaloian@HIDDEN> > Cc: Kaloian Doganov <kaloian@HIDDEN>, > shipmints@HIDDEN, > yavor@HIDDEN, > 80112 <at> debbugs.gnu.org > > > But here we have just one thread waiting for the mutex: the non-main > > thread started by make-thread. The main thread releases the mutex, > > then proceeds to call pselect, and only after pselect returns does the > > main thread attempt to re-acquire the mutex. I would expect the > > thread waiting for the mutex to start running immediately after the > > mutex is released by the main thread, because releasing the mutex > > should trigger the scheduler. If that really doesn't happen, we need > > to understand why. The whole concept of Lisp threads in Emacs is > > built on the assumption that whenever the mutex is released, one of > > the threads waiting for the mutex will start running. Why would a > > system prevent a thread from running when nothing holds it, and there > > are enough CPU resources to let it run? > > I admit I do not have the slightest idea how thread schedulers actually work in > the wild. But I can easily imagine naive hypothetical scenarios where time > slices are being allocated or the scheduler "checks its books" on a certain > interval and decides on a thread's state. If the main thread is given some time > while the new thread is waiting for the global lock, and the scheduler's > granularity happens to be larger than the time needed for the main thread to do > pselect and acquire the global lock again, the main thread would succeed in > doing that before the scheduler "checks its books" again. > > When the scheduler gets around to make a descision which thread gets time and > which one doesn't, it again leaves the new thread waiting for the lock because > the lock is taken by the main thread. But the same situation works on the same GNU/Linux system with the same pthreads and the same scheduler, in a build without GNUstep. So the factor here is definitely something the GNUstep code does and the other builds don't. > > Could it be that the NS GUI code in Emacs somehow stops that thread, although > > the system lets it run? > > AFAIK, the NS world (being GNUstep or Apple Foundation) doesn't suspect this > thread exists at all. It is a POSIX thread, which just runs unencumbered by the > NS world and outside of its control. All of the threads involved in this are POSIX threads. It's just that some of them can run Lisp and execute parts of the Emacs Lisp machine, and others don't. And only those who can run Lisp attempt to take the global lock before they run Lisp.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 6 Jan 2026 08:20:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 06 03:20:58 2026 Received: from localhost ([127.0.0.1]:56487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vd2JF-0004Fi-Oe for submit <at> debbugs.gnu.org; Tue, 06 Jan 2026 03:20:58 -0500 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]:43561) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <kaloian@HIDDEN>) id 1vcrC3-00031F-Da for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 15:28:48 -0500 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 2E2A81D000E2; Mon, 5 Jan 2026 15:28:41 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Mon, 05 Jan 2026 15:28:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doganov.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1767644921; x=1767731321; bh=A7XaVrbFs+ IPcswRfToxbD9P4Bv5J478ODrTy7mrDNA=; b=ADYGgPMBZ3N/SrnQtDHfK8b6yt JigtoIx07AFjp8/FOYn0qyp2gpF0Y6wk1g8JGg0X+n/mmw2yDW2KTYQPeS/9/xX+ Wjo+zVO17D55SjgVo9qx/knn0Sr96j+rUxql+usII+apgUpDvqYQM7kXNHKJ0QSz V9X6VEutV0makcUzg+tz0OWO2sNLlDtwFGmRALhCVQgr/PhR0qXZfWGBo9vfuXHJ YDVGBMG3UHK7qxZLHn3VBvxn0WmLAQ4cZr3Dq4xq+iesg/eSgq26YWZzpRpPDiPB lGWhFJFyqkAjmOWg1AAAPmA1f8TUFCENqxTXgkePwewEPQF5DQpQkBCjjfzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1767644921; x=1767731321; bh=A7XaVrbFs+IPcswRfToxbD9P4Bv5J478ODr Ty7mrDNA=; b=cxrzCh3qGujAuz9GTTMdJ30bH+nMakLIW6I3LuKe/NmJN0B/GN5 Xt2Z1ybYFkaVrv0YReKkWXPAWkFqAUAulKJMa3NF7mvI/P1FlyoHtHYMlU0b7R7P hkFieMGgfpWlDs66njadh1mMyArKVlNaD/SIpAC976uS5k3O7J++3At+Pu2xkK/u B1c73fccCsYzzpPzmHGnh2QuUrgZJ8FXXfPQRRc1xa6FYmyzhFzfEX9a/Dl2JoQh 5Y1ylCyt1I3lN2UJfSV95+tyTU2dxzL2MpFq1+t6744a8Gy7/JJ7tK3xempYiRTS seypSxB2UWbSuFxKsCfKPs5BpAzSh8KXaQQ== X-ME-Sender: <xms:-B5cacF15AdTTdlsBJU0OGTz4ZgyHh3pRBGt7HQ5F2TGn-j96e654Q> <xme:-B5cacNvKqUSW6vxTUks_9fdsID4vIZV5GgfB1j7FgfDQuPFqgKmkTrHLz2BASH5b zJBqTCKAmNtjii3HLWfmJhChPFJbTsbbUz5NbePzW5ubJhUjBwAvg> X-ME-Received: <xmr:-B5caedaUTi_2vIy1xOnCOhWxi3uSfM2eM0pLYIhKoBQE2kbOq91E7lk5_wvBJwkNkks68F_hufa_JOC0NpJht1s> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdelkedviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffkffhvfevufgjfhgfgggtsehttdertddtredvnecuhfhrohhmpefmrghlohhirghn ucffohhgrghnohhvuceokhgrlhhoihgrnhesughoghgrnhhovhdrohhrgheqnecuggftrf grthhtvghrnhepteekteeiffeltdejkeduudelledvieeugfeijeekhfeigeeilefhfeev heegjedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epkhgrlhhoihgrnhesughoghgrnhhovhdrohhrghdpnhgspghrtghpthhtohephedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpth htohepkhgrlhhoihgrnhesughoghgrnhhovhdrohhrghdprhgtphhtthhopehshhhiphhm ihhnthhssehgmhgrihhlrdgtohhmpdhrtghpthhtohephigrvhhorhesghhnuhdrohhrgh dprhgtphhtthhopeektdduuddvseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: <xmx:-B5caZto5LZfA9N-bQ3kQMtD8Wgp9-I8WcE29bWlW42_3knKtoJbqQ> <xmx:-B5cafmINSPBPJ1DEGZM4G1wXqSRH5m2RcIcHmgtRJybhqaY8tcClA> <xmx:-B5cabxhY04z_ZpjZbbd5bZKpVwKOg410s_CWwm_5Ed5N1K8mJNhkw> <xmx:-B5caRPNqCHPMTTaGVlt2OM9O7p9YN-aM4pw-BK2raAYqRFlpPSfDw> <xmx:-R5caU20JxzWAjdL70MXPWzV8LECLfI3TTxtrGanwK-j4uW5cOFiYTIU> Feedback-ID: i5c90432c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 Jan 2026 15:28:39 -0500 (EST) Date: Mon, 05 Jan 2026 22:28:38 +0200 Message-ID: <87secjiz2h.wl-kaloian@HIDDEN> From: Kaloian Doganov <kaloian@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <86ms2uighy.fsf@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> <87v7hjhug1.wl-kaloian@HIDDEN> <86jyxykex0.fsf@HIDDEN> <87tsx2iiwt.wl-kaloian@HIDDEN> <86ms2uighy.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80112 X-Mailman-Approved-At: Tue, 06 Jan 2026 03:20:52 -0500 Cc: Kaloian Doganov <kaloian@HIDDEN>, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN, yavor@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Sat, 03 Jan 2026 22:32:57 +0200, Eli Zaretskii wrote: > > But here we have just one thread waiting for the mutex: the non-main > thread started by make-thread. The main thread releases the mutex, > then proceeds to call pselect, and only after pselect returns does the > main thread attempt to re-acquire the mutex. I would expect the > thread waiting for the mutex to start running immediately after the > mutex is released by the main thread, because releasing the mutex > should trigger the scheduler. If that really doesn't happen, we need > to understand why. The whole concept of Lisp threads in Emacs is > built on the assumption that whenever the mutex is released, one of > the threads waiting for the mutex will start running. Why would a > system prevent a thread from running when nothing holds it, and there > are enough CPU resources to let it run? I admit I do not have the slightest idea how thread schedulers actually work in the wild. But I can easily imagine naive hypothetical scenarios where time slices are being allocated or the scheduler "checks its books" on a certain interval and decides on a thread's state. If the main thread is given some time while the new thread is waiting for the global lock, and the scheduler's granularity happens to be larger than the time needed for the main thread to do pselect and acquire the global lock again, the main thread would succeed in doing that before the scheduler "checks its books" again. When the scheduler gets around to make a descision which thread gets time and which one doesn't, it again leaves the new thread waiting for the lock because the lock is taken by the main thread. I'm not claiming that's exactly what happens here. I have no idea. But still, the new thread appears starved, so it seems that it suffers from some sort of scheduler misfortune, however complex the scheduler actually is. I'm wondering whether it is possible for this pselect call in really_call_select to take less time on the NS port, perhaps due to interactions with the fd_handler thread? If so, then it would be easier for the main thread to breeze through really_call_select without giving much chance to the new thread. > Could it be that the NS GUI code in Emacs somehow stops that thread, although > the system lets it run? AFAIK, the NS world (being GNUstep or Apple Foundation) doesn't suspect this thread exists at all. It is a POSIX thread, which just runs unencumbered by the NS world and outside of its control.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 23:32:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 18:32:21 2026 Received: from localhost ([127.0.0.1]:54956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcu3g-0003R7-Tn for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 18:32:21 -0500 Received: from dane.soverin.net ([2a10:de80:1:4091:b9e9:221f:0:1]:52735) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vcu3e-0003Qs-Eq for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 18:32:19 -0500 Received: from smtp.soverin.net (unknown [10.10.4.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4dlVvJ3qnmzfB; Mon, 05 Jan 2026 23:32:12 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4dlVvJ0h9GzKH; Mon, 5 Jan 2026 23:32:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1767655932; bh=2mvWZkeKzTFEWVB03KjX/4OxEFQI7vBEToYEwINdpUA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BpiYut7jS5NSDoMmiJB19InlKma4Vdl032OHV3x5Bm0QrPNMGmen+rYmO8nkqKxmY hCCWmj8tLIhN2d53dyVqgiDstDOkSZIiLVOL8OT27A516T15S1hRFf/ex8tLjBflwS v+YXbTFYK08Y+rjnxaOV43smzoFL+GeeC9vqMLLsAMZoDrsHKHMd+tDC6InPspaIcn ePs0plZSyLt5UmJ91jciH4YashxGIPYJFr0nFzIMwCkzvuK77gRTmcrDD54mvu4aR3 WRMXna9VOcFm0vCDZ6JJlxpdXTqV+ZELA4frYhWluqdI/gIfHmW7bFqDuq8pwvTLxv ofA/IkL3OM2aA== X-CM-Envelope: MS4xfO1q+uwvF5w3jdT4VdXmnBDtB4fiPfwroFU/se1AOLeQbDrQPef/JSRmSejBcu+hPIbeHbRw3+6XKjgYUPVnUcH4WcxoFMlpHaTMFNq4lUqRvvl4uGb4 iE9IrSZdNMs0DKg6K5fiZU2zB7/hnjGbfomdH/wgTSvHodm09c7z/1n9/vEV/9g+PyAFVgc6kFEDMI/Vr9n4aLp/mCgWETrqiIkfu8x8PJeSMZcj+ceKvOvi eiHt6wsZf0aRxZaAMUGsHMuRGTh046HgL4HLdf6QaG4bPF1pWMS+j8smnEeXcUx7eemqZ2B613MLpxVxZdg4T53F20etRzgg9nVY380WnfU= X-Soverin-Id: 019b9081-0060-7717-a297-78c471b1faa1 Received: from localhost (namib [local]) by namib (OpenSMTPD) with ESMTPA id bca98493; Mon, 5 Jan 2026 23:32:11 +0000 (UTC) Date: Mon, 5 Jan 2026 23:32:11 +0000 From: Alan Third <alan@HIDDEN> To: Yavor Doganov <yavor@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it Message-ID: <aVxJ-04VWjdsNYiV@HIDDEN> Mail-Followup-To: Alan Third <alan@HIDDEN>, Yavor Doganov <yavor@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdgf19m.fsf@HIDDEN> <87qzs34x1s.GNU's_not_UNIX!-yavor@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87qzs34x1s.GNU's_not_UNIX!-yavor@HIDDEN> X-Spampanel-Class: ham X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80112 Cc: Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Mon, Jan 05, 2026 at 10:35:59PM +0200, Yavor Doganov wrote: > Alan Third wrote: > > The runloop can't fully emulate pselect. It's able to emulate read > > fds, but not write fds. > > I believe the GNUstep implementation of NSRunLoop handles write fds > and exception fds. Chances are that Apple's implementation does that > too, although it's undocumented. But how do you set up the sources > for the runloop? And how do you imagine it can be done without an > additional worker thread? I can't remember the exact code, but I looked into it once and IIRC you can wrap a bare fd in an NSFileHandle object and then set up an NSFileHandleDataAvailableNotification. I assume that you could use that to emulate a select call, but I'm quite out of my depth here. There is no equivalent NSFileHandleCanWriteNotification or whatever, so I gave up. > > I suspect that changing it to: > > > > if (![NSThread isMainThread]) > > return thread_select (pselect, nfds, readfds, writefds, > > exceptfds, timeout, sigmask); > > else > > ... > > > > would fix this and retain whatever behaviour Gerd was aiming for. > > This is basically the patch I proposed for Bug#80110. It fixes the > freezes described there but not this bug. Ah, apologies, I didn't realise this was a different bug report. -- Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 23:16:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 18:16:30 2026
Received: from localhost ([127.0.0.1]:54878 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vctoM-0002e6-0N
for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 18:16:30 -0500
Received: from dane.soverin.net ([185.233.34.11]:41925)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vctoH-0002dn-OD
for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 18:16:27 -0500
Received: from smtp.soverin.net (unknown [10.10.4.100])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by dane.soverin.net (Postfix) with ESMTPS id 4dlVXz019lzpMG;
Mon, 05 Jan 2026 23:16:19 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by
soverin.net (Postfix) with ESMTPSA id 4dlVXy4PmVzKH;
Mon, 5 Jan 2026 23:16:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
t=1767654978; bh=OyhZSdvrxS0xc+FE1UQu/et4AqneiBR74V7G6+Riqd8=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=P5zqldRHoBlTXQRnmLWdYnba5hPZsyp1USR5pUWh6umaSAwtd8+6hmHjWVag/6FwF
griIObjHSQ4gvcRZe6o7zqKvrXJBB1by78wGn4dyTfqI5bpbkhxCBjyzD2QVEnIhLa
ztWygsgPOU2oH1mhRLlWENXdreDIHuwQ0f43IZsopf2l+ZW4qzTJyZbB147J4z18nA
teAPkHuTLMct0Xw/BsHIPbS/M1IZXcuULJ+7ASZMdTXRrNqrhrwUDJmqK46qeWrg6J
9Z96raM7poJgs5BUuoe7JUKmnfZcPsxJtWOO3kGszXLrJrnRybQZbc2XAT4+/PwQPT
/6POUPneIDXOQ==
X-CM-Envelope: MS4xfIOzMruMtmMZawd1CD+K2oaoyCDcuaELZrCm96mJv938By7a7HLMbvFRi1qvt4K2dkD7riLTBqO7tu1rYQMar1EdEXmzLi3QGorcq7mHKnb4BiRWeY8A
esPHNAw1/Ag/BQr5QZm/ypEe8c2SjvMO1IZP1DiZvYqJ26u8A7KclsKZjuvQ+kOTZnixXLTpHZp2AprcjsrlYKXB9eGhfDxNwfDaPUoqIwyOjVhhj9dLlp7q
sfTiczvTS3xt0fmJ6/X9OweLllfLXBHkcDRRZC3/48RNmMdf52urK/ZYHXqNZkC96bQSNcsaTkimExKBgjOyGrwSUAiUK7SjpW5Hv1FzJuw=
X-Soverin-Id: 019b9072-71d0-7ca0-9e57-a1d590b42b70
Received: from localhost (namib [local])
by namib (OpenSMTPD) with ESMTPA id bf01f719;
Mon, 5 Jan 2026 23:16:17 +0000 (UTC)
Date: Mon, 5 Jan 2026 23:16:17 +0000
From: Alan Third <alan@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
Message-ID: <aVxGQZycMEKv484Y@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, Yavor Doganov <yavor@HIDDEN>,
kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86pl7of946.fsf@HIDDEN>
X-Spampanel-Class: ham
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80112
Cc: Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On Mon, Jan 05, 2026 at 04:05:13PM +0200, Eli Zaretskii wrote:
> static void
> really_call_select (void *arg)
> {
> struct select_args *sa = arg;
> struct thread_state *self = current_thread;
> sigset_t oldset;
>
> block_interrupt_signal (&oldset);
> self->not_holding_lock = 1;
> release_global_lock (); <<<<<<<<<<<<<< (1)
> restore_signal_mask (&oldset);
>
> sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds,
> sa->timeout, sa->sigmask); <<<<<<<<<<<<<< (2)
>
> release_select_lock ();
>
> block_interrupt_signal (&oldset);
> /* If we were interrupted by C-g while inside sa->func above, the
> signal handler could have called maybe_reacquire_global_lock, in
> which case we are already holding the lock and shouldn't try
> taking it again, or else we will hang forever. */
> if (self->not_holding_lock)
> {
> acquire_global_lock (self); <<<<<<<<<<<<<< (3)
> self->not_holding_lock = 0;
> }
> restore_signal_mask (&oldset);
> }
>
> As you can see, it (1) releases the global lock, (2) calls sa->func
> (which should be pselect in your case), and only then (3) attempts to
> re-acquire the global lock. So how can it "immediately acquire back"
> the lock, bypassing the call to pselect??
Sorry, this is probably a really stupid question, but the NS main
thread calls pselect like this:
struct timespec t = {0, 0};
thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
Is it possible that pselect with those arguments is acting as a no-op
and the main thread is just blasting right through without ever
yielding to another thread?
--
Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 20:36:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 15:36:20 2026
Received: from localhost ([127.0.0.1]:54434 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vcrJM-0003Qo-Gl
for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 15:36:20 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:59130)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vcrJJ-0003QQ-GR
for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 15:36:18 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>)
id 1vcrJC-0004Wm-W7; Mon, 05 Jan 2026 15:36:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From:
Date; bh=IWTaMSweeOqoDQa6ZO6+Ik0nfrcNM3KXITWtJOlNNrA=; b=S/73VM3D+mvar1GwZI+R
w0+11YzKetmOEd01P67oS/zV69DRiL2G6InYGG5kuo3mGstPaQZClhUOFuW23s259KUwDkWemr9Qc
ugD05NBQjtWSV1yD2TRuMLVA2yTaluGUB3b9r3MDnNF2PI4lK2CBlvV32kkN/8OAvq8658CmfGHxj
TnLdpK4vC9ZX+g27KqMi1LdI6N5wpNQ8mX8+lYonYotfZadSKOiT0DuJmslhaAE1fsi+Q9LAjCuvQ
duRF/U28ndLtArsxtyzyJW3R9aRtdW5LK8fl4l4fGRsa4eBvi+v6SfpAoFtIQAKqgTKDVyt7xkByC
muq3o056kNlSnQ==;
Date: Mon, 05 Jan 2026 22:35:59 +0200
Message-ID: <87qzs34x1s.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
In-Reply-To: <86ikdgf19m.fsf@HIDDEN>
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdgf19m.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org,
Alan Third <alan@HIDDEN>, shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Eli Zaretskii wrote:
> > From: Yavor Doganov <yavor@HIDDEN>
> > > Also, does it help to insert a call to sched_yield or pthread_yield
> > > between the call to release_select_lock and the subsequent call to
> > > block_interrupt_signal?
> >
> > No, it doesn't help.
>
> Hmm... what about setting sa->timeout to some short time, like 10
> msec, when it is zero? does that change anything in what happens?
That works. Actually, setting it to 1 nanosecond is enough to make it
work on my machine (tried both the simple Lisp expression and the
Wanderlust issue). I guess it has the same effect as the sleep call.
> Hmm... perhaps the fact that the additional NS thread repeatedly calls
> pselect somehow causes the scheduler not let the non-main Lisp thread
> run?
That's what I imagine is happening, although I cannot explain why.
> In which case perhaps using a non-default scheduler (like SCHED_RR)
> will help?
SCHED_RR/SCHED_FIFO/etc are available only to privileged processes.
(In my naivity, I tried this approach yesterday in sys_thread_create
only to be greeted with EPERM.)
Alan Third wrote:
> The runloop can't fully emulate pselect. It's able to emulate read
> fds, but not write fds.
I believe the GNUstep implementation of NSRunLoop handles write fds
and exception fds. Chances are that Apple's implementation does that
too, although it's undocumented. But how do you set up the sources
for the runloop? And how do you imagine it can be done without an
additional worker thread?
> I think that what's going on here is that when the non-main thread
> falls through to [NSApp run], it starts its own runloop.
The bug happens even if the [NSApp run] call is guarded with a
condition ([NSThread isMainThread]) or ns_select_1 returns early.
> AFAICT, both these branches do basically the same thing:
>
> if (![NSThread isMainThread]
> || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
> thread_select (pselect, nfds, readfds, writefds,
> exceptfds, timeout, sigmask);
> else
> {
> struct timespec t = {0, 0};
> thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
> }
>
> I'm not sure why the first one has to run thread_select if the timeout
> is zero, but it should absolutely *return* the result of thread_select
> when it's the main thread.
That's my humble opinion, too.
> I suspect that changing it to:
>
> if (![NSThread isMainThread])
> return thread_select (pselect, nfds, readfds, writefds,
> exceptfds, timeout, sigmask);
> else
> ...
>
> would fix this and retain whatever behaviour Gerd was aiming for.
This is basically the patch I proposed for Bug#80110. It fixes the
freezes described there but not this bug.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 19:49:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 14:49:44 2026 Received: from localhost ([127.0.0.1]:54299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcqaG-0000jY-9e for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 14:49:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46492) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vcqaD-0000j7-RP for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 14:49:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vcqa6-0005jM-Or; Mon, 05 Jan 2026 14:49:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=U0LbovXQx2taAr2NgmrtyKjUp6PmKGd39RowPZOQxHs=; b=sh3Klk6R5a0G OHl+ESz57ttRg96MfscSAMwVAfASOtOFcBgBaOvFzz/jyXnTzp74ghz3sEuerO80qcMOfaVrIQNOH RkAyyTFkoYqKGf8xD8+UEvaJROh+JSIPhpmpww43wiFzQJmMa7fuK6I+HYrcYuHQAEB56zKCpWpEW B0hC6wzh/58LUZtk/uh3F14O4oZUhI0NkE/yFZqnSvjQMnFoK57McY9pJ8jwFZrof5uINSchTHb21 hLMbGhOzEcBxjeCBMoXkM5scouqIf+7NwEjlG4q7d9KwTiBiqb05rCmUvwq9lE5Ye6tAMoo+Iu+rN u5DAWXpDBIVu5suEKm2upg==; Date: Mon, 05 Jan 2026 21:49:16 +0200 Message-Id: <86bjj7g7r7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Alan Third <alan@HIDDEN> In-Reply-To: <aVwE-C3IHMzltwyB@HIDDEN> (message from Alan Third on Mon, 5 Jan 2026 18:37:44 +0000) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdgf19m.fsf@HIDDEN> <aVwE-C3IHMzltwyB@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 5 Jan 2026 18:37:44 +0000 > From: Alan Third <alan@HIDDEN> > Cc: Yavor Doganov <yavor@HIDDEN>, kaloian@HIDDEN, > 80112 <at> debbugs.gnu.org, shipmints@HIDDEN > > I suspect that changing it to: > > if (![NSThread isMainThread]) > return thread_select (pselect, nfds, readfds, writefds, > exceptfds, timeout, sigmask); > else > ... > > would fix this and retain whatever behaviour Gerd was aiming for. > (IIRC he wanted the main thread to always run the runloop so it would > process keyboard input even when the timeout was zero.) Thanks. Yavor, could you try running with the above change for a while and seeing if that fixes the problems without bringing up new ones?
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 18:37:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 13:37:54 2026
Received: from localhost ([127.0.0.1]:53439 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vcpSj-0003h8-UT
for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 13:37:54 -0500
Received: from dane.soverin.net ([2a10:de80:1:4091:b9e9:2219:0:1]:36809)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <alan@HIDDEN>) id 1vcpSh-0003gh-SG
for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 13:37:52 -0500
Received: from smtp.soverin.net (unknown [10.10.4.99])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by dane.soverin.net (Postfix) with ESMTPS id 4dlNMY6CvRzBR;
Mon, 05 Jan 2026 18:37:45 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net
(Postfix) with ESMTPSA id 4dlNMY3466z9B;
Mon, 5 Jan 2026 18:37:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin;
t=1767638265; bh=YB9erpq+Sios7UEcSy3QkumlebnJRtdDOapl3cC3knE=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=glhbMrrNKPf/vT0/iewspVgal3L8G4f/58iucY+epN+X6UAOUqcp73UQa+di9aeSU
/kF0jQSVMVYiWo7ozUclJOsiYFP+c6f5kOQX/pxFLVj+ViSWuMSiBBqqZ5U3r1EUAP
ck3lnBEPk8xvDlMgIdOJcx5o37/FJsatgZd8im8HRhbKKJe/qUfsF7V9eSMQ1HaTsj
uslfbaAXVjgVRjPkrk1C+skIGu9REFsP+jJrJpQAaH/5oKFvPn9I6ENiIhJksT/T6j
cOzigkvoZAJ8L9MEAwazHTdrXG6VB51lLrpCjXce8JswdQMd8G2j2cNvN4n0E9O2ap
FyFmceif3athg==
X-CM-Envelope: MS4xfLhD7fWLcWqolOxy0F/SynDsMz9sAZIaTHDvR5liiHfJD+B34hLpInq541hz9/I30fKxWTupfVraJa1BMOI4o5vbpcudozLzrxUXvGtkdmvuA36w99xQ
SxoNgSPyLYQlbEW+In9Ypj+ZXHV27Cnd4e7EPbpb5xpwUGtNIAmKp9F5UrJvqk4k3zToL8Mefi4PEoL1CH7R8qgca2FlVcL/J7QpRA/zlx+QB9ElYX7hL32z
8H2KxLiy08X1Sqo9rZVHmiYB0tLNmcXFrbi9zuJ3KMeWEQhG+fT5YGhUCDyhlu2fgIU4H3duKg+JXaRfQiB2DBpfKJhhBEm3kfmeUUOOEVI=
X-Soverin-Id: 019b8f73-6ca8-7823-971e-a09aab9170d0
Received: from localhost (namib [local])
by namib (OpenSMTPD) with ESMTPA id f0ed8013;
Mon, 5 Jan 2026 18:37:44 +0000 (UTC)
Date: Mon, 5 Jan 2026 18:37:44 +0000
From: Alan Third <alan@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but
doesn't start it
Message-ID: <aVwE-C3IHMzltwyB@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, Yavor Doganov <yavor@HIDDEN>,
kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
<87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN>
<87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> <86ikdgf19m.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86ikdgf19m.fsf@HIDDEN>
X-Spampanel-Class: ham
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 80112
Cc: Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On Mon, Jan 05, 2026 at 06:54:45PM +0200, Eli Zaretskii wrote:
> > > > I should mention that the NS port, only when in GUI mode, has one
> > > > additional thread that regularly calls pselect:
> > >
> > > This additional thread might be the missing piece, especially because
> > > it calls pselect (with what descriptors, btw?).
> >
> > As I said in the other bug, I don't understand the code well (see the
> > fd_handler: method in nsterm.m, it's pure C). The interaction between
> > ns_select and this helper thread were the source of many problems, see
> > for example Bug#25265 (yet another NS-specific make-thread issue).
>
> Alan, could you perhaps explain what that thread does and why it calls
> pselect in a loop?
The NS runloop needs to run in the main thread, whoever wrote this
decided the best time to run it was at the same time as emacs tries to
do a pselect call.
This makes sense because the runloop detects input and therefore
should be able to cancel pselect.
The runloop can't fully emulate pselect. It's able to emulate read
fds, but not write fds. This means we need to have an actual call to
pselect, which is what the fd_handler thread is for. The threads
communicate through a mixture of pipes and custom NS events.
Most of ns_select_1 is setting up the fd_handler thread, and handling
its result.
> > > Think about it: that thread just waits for the mutex, and since
> > > there's enough execution units to run it even though that additional
> > > NS thread is around, why would the scheduler NOT run it? what stops
> > > it?
> >
> > I agree it is truly bewildering. I don't agree that it's not possible
> > because this is what I am experiencing.
>
> I didn't say it was impossible, because it clearly is happening.
> Something prevents the non-main thread from running at that point, and
> we need to understand what that something is.
I think that what's going on here is that when the non-main thread
falls through to [NSApp run], it starts its own runloop. This is a
feature of *step, each thread is able to run its own runloop. This
runloop, however, never actually receives any events, so there's
nothing to tell it to stop and return. It will just sit waiting for
incoming events forever.
All the actual events are sent to the main thread's runloop.
We have no use for a runloop in non-main threads, so ns_select used to
return before running the loop. Now it doesn't.
AFAICT, both these branches do basically the same thing:
if (![NSThread isMainThread]
|| (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
thread_select (pselect, nfds, readfds, writefds,
exceptfds, timeout, sigmask);
else
{
struct timespec t = {0, 0};
thread_select (pselect, 0, NULL, NULL, NULL, &t, sigmask);
}
I'm not sure why the first one has to run thread_select if the timeout
is zero, but it should absolutely *return* the result of thread_select
when it's the main thread.
I suspect that changing it to:
if (![NSThread isMainThread])
return thread_select (pselect, nfds, readfds, writefds,
exceptfds, timeout, sigmask);
else
...
would fix this and retain whatever behaviour Gerd was aiming for.
(IIRC he wanted the main thread to always run the runloop so it would
process keyboard input even when the timeout was zero.)
--
Alan Third
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 16:55:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 11:55:00 2026 Received: from localhost ([127.0.0.1]:53027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcnrA-0005i1-0C for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 11:55:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38448) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vcnr7-0005hd-EI for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 11:54:58 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vcnr1-00044e-4t; Mon, 05 Jan 2026 11:54:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=a/UkJA8G6yXQ8hBG7gJ6Zsd7361AGif06S6tR6kDPgc=; b=aVxN8WBZjiow ZT/4Okd76CF2sVMa6dE/IG7A3gUa5IfGsh+02/z9PQmLe6iRZOEFFVzcPTsuoxW8jXIUmx1cnkRMh RDCxBKbblYTPtRRAbEkGeeorK3U9li9jwePmcl2NjU4esuIerz+d7W1yPdQdcDs+ZXihuSZXZOXef ALhqG+xekrWv87KlZ7VlVhoT3CxPRyMG+BYKBJpP1Up1PW2k7KfPaS7UYDRHqKEAAoalCVAz8OeWO /i+EKVL6LlFaIQwJmfjEb4O5waAwGaaOiBoWsngLcFUOnMfYbYOyKzeKaXAL4o1Ca5/ugnXB0KUdo odQrW4Bv3j8B6wcZvXG5Fw==; Date: Mon, 05 Jan 2026 18:54:45 +0200 Message-Id: <86ikdgf19m.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Yavor Doganov <yavor@HIDDEN>, Alan Third <alan@HIDDEN> In-Reply-To: <87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor Doganov on Mon, 05 Jan 2026 17:35:34 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> <87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Mon, 05 Jan 2026 17:35:34 +0200 > From: Yavor Doganov <yavor@HIDDEN> > Cc: Yavor Doganov <yavor@HIDDEN>, > kaloian@HIDDEN, > 80112 <at> debbugs.gnu.org, > shipmints@HIDDEN > > Eli Zaretskii wrote: > > > From: Yavor Doganov <yavor@HIDDEN> > > > That's a pretty standard Debian GNU/Linux installation, Intel CPU, 6 > > > cores, stock kernel/toolchain as provided by Debian. > > > > Yes, but doesn't NS add some threads and perhaps some synchronization > > calls to the soup? > > What do you mean by NS? GNUstep? I also thought that GNUstep might > be doing something specific related to threads so I spent some time > checking the code -- especially the process initialization and the > AppKit initialization. I couldn't find anything suspicious, neither > in Base nor GUI. Yes, I meant GNUstep, sorry for confusing terminology. > > > The main thread releases the mutexin really_call_select and > > > immediately acquires it back > > > > Sorry, I don't understand this. Here's really_call_select: > > [...] > > As you can see, it (1) releases the global lock, (2) calls sa->func > > (which should be pselect in your case), and only then (3) attempts to > > re-acquire the global lock. So how can it "immediately acquire back" > > the lock, bypassing the call to pselect?? > > You are right; I totally missed this. We need to unlock this mystery somehow. > > > I should mention that the NS port, only when in GUI mode, has one > > > additional thread that regularly calls pselect: > > > > This additional thread might be the missing piece, especially because > > it calls pselect (with what descriptors, btw?). > > As I said in the other bug, I don't understand the code well (see the > fd_handler: method in nsterm.m, it's pure C). The interaction between > ns_select and this helper thread were the source of many problems, see > for example Bug#25265 (yet another NS-specific make-thread issue). Alan, could you perhaps explain what that thread does and why it calls pselect in a loop? > > Think about it: that thread just waits for the mutex, and since > > there's enough execution units to run it even though that additional > > NS thread is around, why would the scheduler NOT run it? what stops > > it? > > I agree it is truly bewildering. I don't agree that it's not possible > because this is what I am experiencing. I didn't say it was impossible, because it clearly is happening. Something prevents the non-main thread from running at that point, and we need to understand what that something is. > > > > Which thread executes the printf? > > > > > > The main thread, always. > > > > And what is the value of sa->timeout in these cases? > > Both struct members are always 0. > > > Also, does it help to insert a call to sched_yield or pthread_yield > > between the call to release_select_lock and the subsequent call to > > block_interrupt_signal? > > No, it doesn't help. Hmm... what about setting sa->timeout to some short time, like 10 msec, when it is zero? does that change anything in what happens? > > Btw, the 1-3 sec delay before displaying "Hello" is also abnormal: > > what exactly happens during these 3 sec? > > I agree that it is abnormal. During that time, I can use Emacs just > fine. There are 2-4 (rarely 5) iterations through really_call_select > until the result appears. > > > And if there is indeed a race condition/concurrency issue, then who > > races whom? > > I cannot answer this question. Hmm... perhaps the fact that the additional NS thread repeatedly calls pselect somehow causes the scheduler not let the non-main Lisp thread run? In which case perhaps using a non-default scheduler (like SCHED_RR) will help? See this Stackoverflow discussion: https://stackoverflow.com/questions/6449732/fair-critical-section-linux
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 15:36:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 10:36:23 2026 Received: from localhost ([127.0.0.1]:52763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcmd5-0001LK-4w for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 10:36:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37104) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vcmd2-0001L1-S5 for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 10:36:21 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vcmcw-0004Kj-IL; Mon, 05 Jan 2026 10:36:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From: Date; bh=8WlPtr8Sy5XRwV9xdh6tblN2IZ5VB2Y00po+k+IANsM=; b=eIN9Yk3cRhv+BMa30LuP T7XfOvKtEkb9uR5bcH4bDw/YqG+zO3FA+abcLvrn8HCc66YqmNt9w/eVnot61XABA8EFaGvxmSq9H 3g+Cil7na3t9UwVQ7GLiktH5bTIFsZOTEX8sQGObCjMkarxuajMyKYaKLckXAOdHHQwxOjcRVyunk 8Xf26AL6XCBoLiYTO6U2hIERcpryVnEyeAkbHjo1awaFMevIxtjsBpVC+ZNbwCR1PYdOwH8rd3t3x rcBS+OLZXSwuFaNOyJi+nyWdEl59trfQKkBbX7UDbwuY3wULj8EhxUj+PHxF4JSju+zV1w3GqS5f/ VhXgG4GVrTvvFQ==; Date: Mon, 05 Jan 2026 17:35:34 +0200 Message-ID: <87h5t0t6m1.GNU's_not_UNIX!-yavor@HIDDEN> From: Yavor Doganov <yavor@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <86pl7of946.fsf@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> <86pl7of946.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: The GNU Emacs Church (Bulgarian Eparchy) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii wrote: > > From: Yavor Doganov <yavor@HIDDEN> > > That's a pretty standard Debian GNU/Linux installation, Intel CPU, 6 > > cores, stock kernel/toolchain as provided by Debian. > > Yes, but doesn't NS add some threads and perhaps some synchronization > calls to the soup? What do you mean by NS? GNUstep? I also thought that GNUstep might be doing something specific related to threads so I spent some time checking the code -- especially the process initialization and the AppKit initialization. I couldn't find anything suspicious, neither in Base nor GUI. > > The main thread releases the mutexin really_call_select and > > immediately acquires it back > > Sorry, I don't understand this. Here's really_call_select: > [...] > As you can see, it (1) releases the global lock, (2) calls sa->func > (which should be pselect in your case), and only then (3) attempts to > re-acquire the global lock. So how can it "immediately acquire back" > the lock, bypassing the call to pselect?? You are right; I totally missed this. > > I should mention that the NS port, only when in GUI mode, has one > > additional thread that regularly calls pselect: > > This additional thread might be the missing piece, especially because > it calls pselect (with what descriptors, btw?). As I said in the other bug, I don't understand the code well (see the fd_handler: method in nsterm.m, it's pure C). The interaction between ns_select and this helper thread were the source of many problems, see for example Bug#25265 (yet another NS-specific make-thread issue). > Think about it: that thread just waits for the mutex, and since > there's enough execution units to run it even though that additional > NS thread is around, why would the scheduler NOT run it? what stops > it? I agree it is truly bewildering. I don't agree that it's not possible because this is what I am experiencing. > > I suppose that if/when we understand why it will be trivial to fix > > it. > > See above: the code which implements this is so simple that it > hurts. I am not a programmer so it's not so simple for me. > > > Which thread executes the printf? > > > > The main thread, always. > > And what is the value of sa->timeout in these cases? Both struct members are always 0. > Also, does it help to insert a call to sched_yield or pthread_yield > between the call to release_select_lock and the subsequent call to > block_interrupt_signal? No, it doesn't help. > Btw, the 1-3 sec delay before displaying "Hello" is also abnormal: > what exactly happens during these 3 sec? I agree that it is abnormal. During that time, I can use Emacs just fine. There are 2-4 (rarely 5) iterations through really_call_select until the result appears. > And if there is indeed a race condition/concurrency issue, then who > races whom? I cannot answer this question.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 14:06:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 09:06:12 2026
Received: from localhost ([127.0.0.1]:51349 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vclDn-0004OO-6i
for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 09:06:11 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:52206)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vclDk-0004O6-Jt
for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 09:06:09 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vclDf-0002X6-3e; Mon, 05 Jan 2026 09:06:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=LYXl9a06DbdPXB4v7/wxKbW6kubX8mIVBP0xLOeRbec=; b=CVFW7x63ES7x
jMS/7cv+R1vW1GfKGdWJyWYL8V5c+9Q1gDy6ncUiQndIwkG9Ei0vBYE1ENZI9ygzVSmsCilpAxLEV
rjI0+S3KRwNmBu4GRC+0sHTyEbQNdTvCrnEcjJ0H/J9BWwN/RITWoWWkOihDlWUCWVjVWMxLKfWsv
Jn/V6ORUShpCMV+wkA0AHJ9HwDO3blcLwx/BIhP6uTZR8jx1lKsWrz0gAg9siUSw1K5EmaH8vxtol
tstgOyu6tddjZ+tfUSonRkQNC2wfLUx/8EYl+DjgiSbYc5mtKozJmd+/Tg0F5jN/m0q/O2ZjMbCPK
aXg3eTuk0J9sxaEdqJyqBg==;
Date: Mon, 05 Jan 2026 16:05:13 +0200
Message-Id: <86pl7of946.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
In-Reply-To: <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor
Doganov on Mon, 05 Jan 2026 14:59:16 +0200)
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN>
<86h5t2kdug.fsf@HIDDEN> <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN,
yavor@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Mon, 05 Jan 2026 14:59:16 +0200
> From: Yavor Doganov <yavor@HIDDEN>
> Cc: kaloian@HIDDEN,
> 80112 <at> debbugs.gnu.org,
> shipmints@HIDDEN,
> yavor@HIDDEN
>
> > Does the system's thread scheduler have some policy to prefer the
> > thread that was just preempted, and allow it to re-acquire the mutex
> > it just released, instead of giving the mutex to another thread?
>
> That's a pretty standard Debian GNU/Linux installation, Intel CPU, 6
> cores, stock kernel/toolchain as provided by Debian.
Yes, but doesn't NS add some threads and perhaps some synchronization
calls to the soup?
> > And note that the main thread still has to call pselect after it
> > releases the mutex, whereas the other thread just waits for the mutex.
> > So this really is strange behavior of the thread scheduling.
>
> But that's not what's happening. The main thread releases the mutex
> in really_call_select and immediately acquires it back while still
> whithin the same function (self->not_holding_lock is true and the
> waiting thread didn't acquire the lock so the main thread grabs it
> again). That's why the trick with sleep as a replacement of
> release_select_lock works.
Sorry, I don't understand this. Here's really_call_select:
static void
really_call_select (void *arg)
{
struct select_args *sa = arg;
struct thread_state *self = current_thread;
sigset_t oldset;
block_interrupt_signal (&oldset);
self->not_holding_lock = 1;
release_global_lock (); <<<<<<<<<<<<<< (1)
restore_signal_mask (&oldset);
sa->result = (sa->func) (sa->max_fds, sa->rfds, sa->wfds, sa->efds,
sa->timeout, sa->sigmask); <<<<<<<<<<<<<< (2)
release_select_lock ();
block_interrupt_signal (&oldset);
/* If we were interrupted by C-g while inside sa->func above, the
signal handler could have called maybe_reacquire_global_lock, in
which case we are already holding the lock and shouldn't try
taking it again, or else we will hang forever. */
if (self->not_holding_lock)
{
acquire_global_lock (self); <<<<<<<<<<<<<< (3)
self->not_holding_lock = 0;
}
restore_signal_mask (&oldset);
}
As you can see, it (1) releases the global lock, (2) calls sa->func
(which should be pselect in your case), and only then (3) attempts to
re-acquire the global lock. So how can it "immediately acquire back"
the lock, bypassing the call to pselect??
What _should_ happen is that when the main thread releases the global
lock, the non-main thread, which waited for the lock, acquires the
lock and proceeds to run its Lisp code. The main thread then returns
from pselect, calls acquire_global_lock, and gets stuck there, waiting
for the global lock to be released.
The fact that self->not_holding_lock just means there was no C-g
interrupt (which btw can only happen on a TTY frame, where C-g
triggers SIGINT). It is normal.
What am I missing here?
> I should mention that the NS port, only when in GUI mode, has one
> additional thread that regularly calls pselect: it is started right
> after the NSApp global variable is initialized by +sharedApplication
> in ns_term_init. This thread doesn't wait for the global lock but
> it's always alive so the system scheduler has one additional thread to
> choose from.
This additional thread might be the missing piece, especially because
it calls pselect (with what descriptors, btw?). But its mere
existence, and the fact that there's one more thread to schedule,
don't yet explain why the non-main thread started by make-thread
doesn't get to run immediately when the global lock is released.
Think about it: that thread just waits for the mutex, and since
there's enough execution units to run it even though that additional
NS thread is around, why would the scheduler NOT run it? what stops
it?
> This is one notable difference between NS and the other ports but it
> still doesn't explain why the Lisp thread is not given a chance.
The MS-Windows port also has additional threads that are not subject
to the global lock, so this is not unique to NS. What might be unique
is what that additional thread does, not that it exists.
> > > > . when the non-main thread exits, the main thread acquires the
> > > > global lock again
> > >
> > > The non-main thread never exits as it never manages to acquire the
> > > global lock; the main thread releases and acquires the lock
> > > periodically.
> >
> > How can that happen?
>
> I suppose that if/when we understand why it will be trivial to fix it.
See above: the code which implements this is so simple that it hurts.
Unless one of the lines between release_global_lock call and the
subsequent acquire_global_lock call does something that doesn't meet
the eye, I cannot understand how what you describe can happen.
> > > Note that merely adding the following printf statement in
> > > really_call_select right after the release_global_lock call
> > >
> > > printf ("really_call_select: global lock released: %s\n",
> > > (getpid () == gettid ()) ? "main thread" : "new thread");
> > >
> > > makes evaluating the expression to print "Hello" after 1-3 seconds
> > > delay which is an indication of some race condition/concurrency
> > > problem.
> >
> > Which thread executes the printf?
>
> The main thread, always.
And what is the value of sa->timeout in these cases?
Also, does it help to insert a call to sched_yield or pthread_yield
between the call to release_select_lock and the subsequent call to
block_interrupt_signal?
Btw, the 1-3 sec delay before displaying "Hello" is also abnormal:
what exactly happens during these 3 sec? And if there is indeed a
race condition/concurrency issue, then who races whom?
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 5 Jan 2026 12:59:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 05 07:59:34 2026
Received: from localhost ([127.0.0.1]:51059 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vckBK-0000YT-A0
for submit <at> debbugs.gnu.org; Mon, 05 Jan 2026 07:59:34 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:49450)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vckBI-0000YB-4d
for 80112 <at> debbugs.gnu.org; Mon, 05 Jan 2026 07:59:32 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>)
id 1vckBC-0008L4-I9; Mon, 05 Jan 2026 07:59:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From:
Date; bh=dcrfIjkXAkgEkCm17z7lclkwB4g3GX4teMFaNWzgwk0=; b=ktP4G6+IEFMVqflYwzuo
3b0cqApKh63TX8HLVbOE/GKyGdRbb230NochOCKmz0Uh2TH5mbb0Qvlz8JXaaBT+/oyNjf+P2TPVB
HsSHhcuhKorny8C45EopOMqdtVNCTar1idZW9XgIkdya2dcQFrUTZfOT1DATyAfSTpOJsoBVRxLyo
kAF7ulpFpZgzxRCBMYT249rwfU+sYreCHo7MSiClUyaCq1rfuOgQlhSW6aqy8rtPPMsSsi8GbbTvN
QIKxUy1To3Eb5Aby1PPNm6JbKFCmBiSvOIZudKqKRNqTAv07W74RMVlsOYf+hQEFxM0edgAJwHxJt
XynMFZH2XBUMuw==;
Date: Mon, 05 Jan 2026 14:59:16 +0200
Message-ID: <87a4ys9pwb.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
In-Reply-To: <86h5t2kdug.fsf@HIDDEN>
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
<871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> <86h5t2kdug.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0
Emacs/31.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN,
yavor@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
On Sat, 03 Jan 2026 15:47:19 +0200,
Eli Zaretskii wrote:
> > From: Yavor Doganov <yavor@HIDDEN>
> > > . when the main thread, the one where the above form was evaluated,
> > > becomes idle, and calls thread_select, it releases the global
> > > lock (see really_call_select, which is called by thread_select),
> > > at which point the new thread created above is expected to acquire
> > > the global lock, run its Lisp code, then exit
> >
> > This doesn't happen -- the main thread releases the lock in
> > really_call_select but acquires it back immediately.
>
> The only way I could understand this is that the OS doesn't let the
> other thread run, although it is waiting for the mutex and nothing
> else.
That's how I understand it, too. The big question is *why*.
> Does the system's thread scheduler have some policy to prefer the
> thread that was just preempted, and allow it to re-acquire the mutex
> it just released, instead of giving the mutex to another thread?
That's a pretty standard Debian GNU/Linux installation, Intel CPU, 6
cores, stock kernel/toolchain as provided by Debian.
> And note that the main thread still has to call pselect after it
> releases the mutex, whereas the other thread just waits for the mutex.
> So this really is strange behavior of the thread scheduling.
But that's not what's happening. The main thread releases the mutex
in really_call_select and immediately acquires it back while still
whithin the same function (self->not_holding_lock is true and the
waiting thread didn't acquire the lock so the main thread grabs it
again). That's why the trick with sleep as a replacement of
release_select_lock works.
I should mention that the NS port, only when in GUI mode, has one
additional thread that regularly calls pselect: it is started right
after the NSApp global variable is initialized by +sharedApplication
in ns_term_init. This thread doesn't wait for the global lock but
it's always alive so the system scheduler has one additional thread to
choose from.
This is one notable difference between NS and the other ports but it
still doesn't explain why the Lisp thread is not given a chance.
> > > . when the non-main thread exits, the main thread acquires the
> > > global lock again
> >
> > The non-main thread never exits as it never manages to acquire the
> > global lock; the main thread releases and acquires the lock
> > periodically.
>
> How can that happen?
I suppose that if/when we understand why it will be trivial to fix it.
> > Note that merely adding the following printf statement in
> > really_call_select right after the release_global_lock call
> >
> > printf ("really_call_select: global lock released: %s\n",
> > (getpid () == gettid ()) ? "main thread" : "new thread");
> >
> > makes evaluating the expression to print "Hello" after 1-3 seconds
> > delay which is an indication of some race condition/concurrency
> > problem.
>
> Which thread executes the printf?
The main thread, always.
> > --- a/src/thread.c
> > +++ b/src/thread.c
> > @@ -34,6 +34,8 @@ Copyright (C) 2012-2026 Free Software Foundation, Inc.
> >
> > #if defined HAVE_GLIB && ! defined (HAVE_NS)
> > #include <xgselect.h>
> > +#elif defined NS_IMPL_GNUSTEP
> > +#define release_select_lock() sleep (0)
> > #else
> > #define release_select_lock() do { } while (0)
> > #endif
> >
> > With this change, there is no bug ("Hello" appears immediately) and
> > it's extremely easy to trigger the freeze described in Bug#80110. It
> > happens when wait_reading_process_output (process.c) calls ns_select
> > not from the main thread which then calls [NSApp run].
>
> I believe someone already said that calling [NSApp run] from a
> non-main thread is a no-no?
That's written in Apple's and GNUstep's documentation.
> However, if {NSApp run] is needed to perform redisplay, we must run
> it, or else a non-main thread will be unable to trigger redisplay.
OK but it has the opposite effect if it leads to a full freeze so that
the only way out is to kill Emacs.
> > Stéphane Marks wrote:
> > > So it's likely something else related to the Linux build with
> > > GNUstep. Perhaps the user can verify the test on a Lucid or GTK
> > > build.
> >
> > No, I cannot reproduce with a Lucid or GTK build (also tried Lucid
> > configured with emacs_cv_links_glib=no to force it to use
> > thread_select instead of xg_select).
>
> But Stéphane said it was something specific to NS on GNU/Linux, not
> something specific to GNU/Linux itself.
Right, but he asked me to verify with GTK/Lucid so I did.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 4 Jan 2026 07:36:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 04 02:36:07 2026 Received: from localhost ([127.0.0.1]:41614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vcIeh-0003da-6h for submit <at> debbugs.gnu.org; Sun, 04 Jan 2026 02:36:06 -0500 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]:59649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <kaloian@HIDDEN>) id 1vc7Uh-0005D5-1O for 80112 <at> debbugs.gnu.org; Sat, 03 Jan 2026 14:41:01 -0500 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9CED11400083; Sat, 3 Jan 2026 14:40:53 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sat, 03 Jan 2026 14:40:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doganov.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1767469253; x=1767555653; bh=MIv5Yn0UBQ R94iNC2WkBy7Mmr6pjcrCRO5MKv9eXkzE=; b=tJ6hpmilIdpo4ZmSlra2hwh9rs enwz3Ra34lew7RIx43hhIgjLotrqxSkkAx+E6iodyUfVfltN/GlQep3aP0FByBRv vt+xb5loDt/bnG7gWdzn94CPVu3g/0C+EMXUarFkrN23TPhjiYUP/fJZe/INDGKB l7OuPxIdhPcjBOvZ2eSCfrRQ7/unGeeMYOupisCQJnk9qvE9RXEODDUC+BcKin7c 7wS5uycDK9HzMavVW25bIy045CUmfWdjPOHQZh/LoNwLW9ehmd/Vmu4d3eIHBvQM tvF+yFWwHxRNKKe78q80UYS2Z0OdSnmH2CyBqq8Z11q8mPOYE3jmRUxvCOFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1767469253; x=1767555653; bh=MIv5Yn0UBQR94iNC2WkBy7Mmr6pjcrCRO5M Kv9eXkzE=; b=mV5x6bJrShxZoM1O2XxmZpp5BvbDH/99H4rdiQ/xigy0daT/FKr rnRQGItwKg5U8zfXBv6iOu321te3bbib2Bx46W7yxhNNOz2xJ8zT6ANvOosS6pHk y49duev+3pLRT+0kbpQl0GdLrICGuZuS1R5VQaiGNIRNL1f7MuPGKsAC0W3Egb2a /nBLQewoOa/UBt/VuF2htEAvSjXpGOYWfIhPh72nszpG7itW6BwMhipYVMhbGtYQ cjnXiY0YxvPk9F2Nh37D+JEzR38LaeIzEUpG8YI5ePyzvARKVunduh4Mwvmk2NPG yb0HXmmKvCc0YkxklBKg5Juefq3RpSccebA== X-ME-Sender: <xms:xXBZaRCnknxZzxMwZo_2WM9HoVOrXmMucC7xTHUvOc2PMOhqbX_A3Q> <xme:xXBZaWZodspSzhm00wQxe9jjmyM0zI-vywJ_tZRD5HoQH5Cq-G9Raul1ToTGjIBt5 KFHpK_QUKcgp5EUMDeaIytiL991h49FApddZnDJQyWKkue8sPzhLA> X-ME-Received: <xmr:xXBZaU6qUOuBRfqYaBa7S4fw0C86Y_CD0QfyhOFdbZzE8pCdJUQo09lgiDF3vzfdzzsXT3ZB_dlDgCnUv58o4teT> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdelvdegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffkffhvfevufgjfhgfgggtsehttdertddtredvnecuhfhrohhmpefmrghlohhirghn ucffohhgrghnohhvuceokhgrlhhoihgrnhesughoghgrnhhovhdrohhrgheqnecuggftrf grthhtvghrnhepteekteeiffeltdejkeduudelledvieeugfeijeekhfeigeeilefhfeev heegjedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epkhgrlhhoihgrnhesughoghgrnhhovhdrohhrghdpnhgspghrtghpthhtohephedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpth htohepkhgrlhhoihgrnhesughoghgrnhhovhdrohhrghdprhgtphhtthhopehshhhiphhm ihhnthhssehgmhgrihhlrdgtohhmpdhrtghpthhtohephigrvhhorhesghhnuhdrohhrgh dprhgtphhtthhopeektdduuddvseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: <xmx:xXBZaXbB49NWQygOUqCCZuMd9i117YSNE4s-38_p-A61xmQKFQTx5g> <xmx:xXBZaTggp7kvJzFSbEecs-D0T43nO2gH9rjjDP38BUd0soJ6SenwMg> <xmx:xXBZaY9ht3pQKNste6lORDMlfb6TvkUV1dMEif-ZQRjyKNm8IydnHw> <xmx:xXBZaepLyEm4hINEbptxj6n8Zjc3PZp0OXGHWTCfeog6KXyBX4IY0Q> <xmx:xXBZaZibZCFAJEgpkyNtWtxzV_1Wat0rnWaoMnmORdPlRxusqEZQo7tX> Feedback-ID: i5c90432c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jan 2026 14:40:52 -0500 (EST) Date: Sat, 03 Jan 2026 21:40:50 +0200 Message-ID: <87tsx2iiwt.wl-kaloian@HIDDEN> From: Kaloian Doganov <kaloian@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <86jyxykex0.fsf@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> <87v7hjhug1.wl-kaloian@HIDDEN> <86jyxykex0.fsf@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80112 X-Mailman-Approved-At: Sun, 04 Jan 2026 02:36:00 -0500 Cc: Kaloian Doganov <kaloian@HIDDEN>, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN, yavor@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Sat, 03 Jan 2026 15:24:11 +0200, Eli Zaretskii wrote: > > > Date: Sat, 03 Jan 2026 12:17:02 +0200 > > From: Kaloian Doganov <kaloian@HIDDEN> > > > > I noticed that moving the mouse, or clicking, or pressing keys on the keyboard > > can have the effect on unstalling the new thread. > > This means that there's some additional factor at work here, which > affects how threads are scheduled. My guess was that having incoming events on the main thread's run loop changes the main thread's behavior in some way that leads the scheduler to decide that the new thread can run too. > How many CPU execution units do you have on that system? And I assume > the system was not heavily loaded when you ran these experiments? It is an aarch64 system with 10 cores in a big.LITTLE-like setup (4 performance and 6 efficiency cores). Those are actual physical cores, there's no hyperthreading. For the test, the system was practically idle. At least, as idle as a desktop system could be. > > This all seems like the main thread releases and reacquires the global lock too > > quickly, so the new thread has a very small window of opportunity to acquire it. > > I don't see how this could be true. The "too quickly" part is not up > to the thread, it's up to the system's scheduler. When one Lisp > thread releases the global lock whether another thread, which is ready > to run, will run and succeed to acquire the lock, is up to the OS, > which implements the thread scheduling. That's because Emacs uses the > "normal" system threads to implement Lisp threads. > > So whether the same main thread will immediately re-acquire the lock > depends on whether the OS lets another thread run. We expect that to > happen, and I would be very surprised if on some system it doesn't. I never meant to imply that this surprising behavior has something to do with the Lisp aspect of the threads involved. Sorry I gave that impression. > If the OS does let another thread run, it will normally always grab > t6he lock, because the main thread, which released the lock, has yet > to call pselect and return from that call, before it attempts to > re-acquire the lock. Whereas the other thread is expected to acquire > the lock immediately as soon as the lock is released, since it was > waiting for the lock to be released, and is otherwise ready to run. I have exactly the same mental model. The "too quickly" phrase was an informal, kinda-poetic language to describe what happens from the point of view of the frustrated thread that gets starved. I should have been more careful with the language. > > According to pthread_mutexattr(3) man page on macOS, phread_mutex_t was fair > > until macOS 10.14 (Mojave, released late 2018), when it became non-fair by > > default. So I guess the NS code was working just fine when it was tested on > > macOS back in the day. > > What does "non-fair" mean in this context? And how can we make the > scheduler be "fair"? A fair mutex is a kind of mutex that arranges things so that the next thread acquiring it is the one that waited for it the longest. One could imagine the threads waiting for the lock arranged in a FIFO queue. A non-fair mutex, on the other hand, has no such guarantees. When multiple threads wait to acquire such mutex, *any* one of them could acquire it (after the mutex is released, of course). This could lead to thread starvation, as it may happen that some of the waiting thread(s) are never (or rarely) picked. (Implementation-wise, a fair mutex has more overhead than a non-fair one.) In our case here, my guess is that if pthread_mutex_t was fair on GNU/Linux systems, the main thread wouldn't be able to starve the new thread on NS builds, since the new thread is already waiting for the global lock. Thanks, Kaloian
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 3 Jan 2026 20:33:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 15:33:08 2026 Received: from localhost ([127.0.0.1]:38591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vc8J9-0007yS-3x for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 15:33:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45442) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vc8J6-0007xw-LG for 80112 <at> debbugs.gnu.org; Sat, 03 Jan 2026 15:33:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vc8J1-00073q-7E; Sat, 03 Jan 2026 15:32:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=yp5KghrAm+CmiDRzNDlqYJ6KvMoZMuNM3dNHzBZOghY=; b=X8j+DImmsFGi HFOmUrOVvoMUDZBiYdY1Mn9Im840VmkIZbkJyiCb2KdIYtAXid66NhcWH3YBxLav1oKxV8cPJBGmy 2SznDa1muLIfIWKL2/5TnHlr4rmOgKMDH2GSoJWN1GAcG2DJe0BAsnmPUB7keTsTSeNKJ9eykA+jY M1Y5JW7RqrGpJM48dChrvvOkyBbaO0viks0EDLKCLQVim1yD1343WNhk/u++oP/CQuy6ySu7kWM9G Pix+QdXFINCiznl8cNlfNzocd0Tm9ySEDskKWumoWwXqhi/Q5zeO9OxYLwL24f8rBPaG2ywqyDexI q+9WTD/w2V7KRV0vzo8hwA==; Date: Sat, 03 Jan 2026 22:32:57 +0200 Message-Id: <86ms2uighy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Kaloian Doganov <kaloian@HIDDEN> In-Reply-To: <87tsx2iiwt.wl-kaloian@HIDDEN> (message from Kaloian Doganov on Sat, 03 Jan 2026 21:40:50 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> <87v7hjhug1.wl-kaloian@HIDDEN> <86jyxykex0.fsf@HIDDEN> <87tsx2iiwt.wl-kaloian@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 03 Jan 2026 21:40:50 +0200 > From: Kaloian Doganov <kaloian@HIDDEN> > Cc: Kaloian Doganov <kaloian@HIDDEN>, > shipmints@HIDDEN, > yavor@HIDDEN, > 80112 <at> debbugs.gnu.org > > On Sat, 03 Jan 2026 15:24:11 +0200, > Eli Zaretskii wrote: > > > > > Date: Sat, 03 Jan 2026 12:17:02 +0200 > > > From: Kaloian Doganov <kaloian@HIDDEN> > > > > > > I noticed that moving the mouse, or clicking, or pressing keys on the keyboard > > > can have the effect on unstalling the new thread. > > > > This means that there's some additional factor at work here, which > > affects how threads are scheduled. > > My guess was that having incoming events on the main thread's run loop changes > the main thread's behavior in some way that leads the scheduler to decide that > the new thread can run too. At face value, I cannot understand how this could happen. Maybe more details will explain that, if it's true. > > How many CPU execution units do you have on that system? And I assume > > the system was not heavily loaded when you ran these experiments? > > It is an aarch64 system with 10 cores in a big.LITTLE-like setup (4 performance > and 6 efficiency cores). Those are actual physical cores, there's no > hyperthreading. > > For the test, the system was practically idle. At least, as idle as a desktop > system could be. So there should have been no problems for the OS to schedule the thread which was waiting for the mutex. Curiouser and curiouser. > > I don't see how this could be true. The "too quickly" part is not up > > to the thread, it's up to the system's scheduler. When one Lisp > > thread releases the global lock whether another thread, which is ready > > to run, will run and succeed to acquire the lock, is up to the OS, > > which implements the thread scheduling. That's because Emacs uses the > > "normal" system threads to implement Lisp threads. > > > > So whether the same main thread will immediately re-acquire the lock > > depends on whether the OS lets another thread run. We expect that to > > happen, and I would be very surprised if on some system it doesn't. > > I never meant to imply that this surprising behavior has something to do with > the Lisp aspect of the threads involved. Sorry I gave that impression. This is a misunderstanding: the fact that these threads run the Lisp machine has nothing to do with how they are scheduled. The OS has no idea what these threads run nor the significance of what they run for the Lisp machine in Emacs. > > If the OS does let another thread run, it will normally always grab > > t6he lock, because the main thread, which released the lock, has yet > > to call pselect and return from that call, before it attempts to > > re-acquire the lock. Whereas the other thread is expected to acquire > > the lock immediately as soon as the lock is released, since it was > > waiting for the lock to be released, and is otherwise ready to run. > > I have exactly the same mental model. The "too quickly" phrase was an informal, > kinda-poetic language to describe what happens from the point of view of the > frustrated thread that gets starved. I should have been more careful with the > language. > > > > According to pthread_mutexattr(3) man page on macOS, phread_mutex_t was fair > > > until macOS 10.14 (Mojave, released late 2018), when it became non-fair by > > > default. So I guess the NS code was working just fine when it was tested on > > > macOS back in the day. > > > > What does "non-fair" mean in this context? And how can we make the > > scheduler be "fair"? > > A fair mutex is a kind of mutex that arranges things so that the next thread > acquiring it is the one that waited for it the longest. One could imagine the > threads waiting for the lock arranged in a FIFO queue. > > A non-fair mutex, on the other hand, has no such guarantees. When multiple > threads wait to acquire such mutex, *any* one of them could acquire it (after > the mutex is released, of course). This could lead to thread starvation, as it > may happen that some of the waiting thread(s) are never (or rarely) picked. > > (Implementation-wise, a fair mutex has more overhead than a non-fair one.) > > In our case here, my guess is that if pthread_mutex_t was fair on GNU/Linux > systems, the main thread wouldn't be able to starve the new thread on NS builds, > since the new thread is already waiting for the global lock. But here we have just one thread waiting for the mutex: the non-main thread started by make-thread. The main thread releases the mutex, then proceeds to call pselect, and only after pselect returns does the main thread attempt to re-acquire the mutex. I would expect the thread waiting for the mutex to start running immediately after the mutex is released by the main thread, because releasing the mutex should trigger the scheduler. If that really doesn't happen, we need to understand why. The whole concept of Lisp threads in Emacs is built on the assumption that whenever the mutex is released, one of the threads waiting for the mutex will start running. Why would a system prevent a thread from running when nothing holds it, and there are enough CPU resources to let it run? Could it be that the NS GUI code in Emacs somehow stops that thread, although the system lets it run?
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 3 Jan 2026 16:55:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 11:55:07 2026 Received: from localhost ([127.0.0.1]:37776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vc4uA-0005Td-9C for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 11:55:07 -0500 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:41059) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <kaloian@HIDDEN>) id 1vbyh5-0003ao-Ek for 80112 <at> debbugs.gnu.org; Sat, 03 Jan 2026 05:17:12 -0500 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id 37E8CEC0195; Sat, 3 Jan 2026 05:17:06 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Sat, 03 Jan 2026 05:17:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doganov.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1767435426; x=1767521826; bh=3kJrtx+mxebZnsydfr6wEe+lEj7XQ+gXJ5euOTTiNsA=; b= ZElvq89NKfYiBHF3KVKvjl2jT7QHtMLANAp7rl0G2fvhI/YwRa2K3I7VpgIG7E4p I+8uWz42m5yH9NSKRhlFuZmkBTGO1Po0DAOuDBUWz3xES5wRkooskLCwI+kTk1Oy fTjRxOVGL4GhBidnnvQ/sB61xKsML9vGl6O1ttgdKbVyG1Jwt5/HjoEHJYVzfwba SgRvAnp38c7FwsedIq3xRrgNwc53d5v4kkpi4BaWfryiio6Cz+m6QwQNj+mmHLEx I05xI7ryZg/di+4BBT1HyHEKyw6Gcl3pBGTt4zn7Tpefovu0rbzstfC1e0eXvEl+ lw98f/K45qlQlTY3VY95ew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1767435426; x= 1767521826; bh=3kJrtx+mxebZnsydfr6wEe+lEj7XQ+gXJ5euOTTiNsA=; b=i XzoFJGxMbOFEjdwCGQ+fo3P2KTYDoQy5a+n7txCC3CsoLHjNDDo+W/av9+cnT8Jj /HX2Kx6QBLNArJhpFrmPCVjUVhHVWC9wfFLbVxuhMz1BJGSnmVZrm7fkDGz9fmCz DucN6gUZ1yOIhk/yFP98NvyzSxAFgf3+k20lF8UshvjNOv7qfj6sON4FPcdEkG2v mvkFWomacVzxYMiz09CB0fJxzR3rEHdUJQ6pLRVbMrNtIdJRi67dBkXUyq9ukhKC Ohz1+ebeMfsWV4tzgWBLsakv1ACZRmFxtQSX/KIfE0KIjmtHorsvO2mvk6dCnS3N YNiJnxM96hl96R0ggq8Wg== X-ME-Sender: <xms:oexYacCbmJKOrY6FcZH-6JRFTi1ANkPxSjYJRj51Zg6Jy3dBVdF3pQ> <xme:oexYaaBj-z6jxLIvc17eUXFwOmNK0JV-AOtNBPwgfJR608sUxxldUxdGR_yLKNkC_ Vsyp5vRt-qeAs0ErMiLtfhG3BHszTxVPgF3qhUvzCQjljl7HLvy6w> X-ME-Received: <xmr:oexYaWBVrMmqhtzllAG4ZP4f96v5VyaHZUft6CvsBgYq6eC8iNxgKmuUxtS8gqGx6B-Ws1rqP6mCXkIQRXFctm8M> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdeluddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffkffhvfevufgjfhgfgggtgfesthekredttderjeenucfhrhhomhepmfgrlhhoihgr nhcuffhoghgrnhhovhcuoehkrghlohhirghnseguohhgrghnohhvrdhorhhgqeenucggtf frrghtthgvrhhnpefhheffieevvdffveetheethfdvtefhieffteekvdekieehudelleeu tedvffduudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehkrghlohhirghnseguohhgrghnohhvrdhorhhgpdhnsggprhgtphhtthhopeehpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhssehgmhgrihhlrd gtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohephigrvhho rhesghhnuhdrohhrghdprhgtphhtthhopehkrghlohhirghnseguohhgrghnohhvrdhorh hgpdhrtghpthhtohepkedtudduvdesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: <xmx:oexYadpWqtxwxUVV1UQhyqOOoeB_Ki4ei8PPWneue5qtxnhM2eYrSQ> <xmx:oexYaYkwgx9xKK6pAzADIa2NVwMlhQuGDcnaElDMr4dKZzVws6DhbQ> <xmx:oexYaVwI_CrvfMGYov9KjrbbGu4J_Figh0fGrQNO18k0NplsT1ZhOQ> <xmx:oexYaY94EzF4_Z-EWDuhoFeD1_8SYP9onRLbwPusOhrh54s4BFI0gw> <xmx:ouxYaWGUo-PVGA36MyMGHU9TriK0q-knIOZqWZTbv6MF39CzgpzNC4Xg> Feedback-ID: i5c90432c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jan 2026 05:17:04 -0500 (EST) Date: Sat, 03 Jan 2026 12:17:02 +0200 Message-ID: <87v7hjhug1.wl-kaloian@HIDDEN> From: Kaloian Doganov <kaloian@HIDDEN> To: =?UTF-8?B?U3TDqXBoYW5l?= Marks <shipmints@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it In-Reply-To: <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80112 X-Mailman-Approved-At: Sat, 03 Jan 2026 11:55:04 -0500 Cc: kaloian@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80112 <at> debbugs.gnu.org, Yavor Doganov <yavor@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On Fri, 02 Jan 2026 14:51:04 +0200, Stéphane Marks wrote: > The example works fine for me on macOS for both 30.2 and a fresh master build. So it's likely something else > related to the Linux build with GNUstep. Perhaps the user can verify the test on a Lucid or GTK build. I just tried this with Emacs 30.1 on macOS 15.7.2 (Sequoia) with an M4 CPU. I did multiple attempts and the example runs fine *sometimes*. I can classify the behavior roughly in three different groups: 1. The example runs fine, the "Hello" message is emitted immediately by the new thread. 2. The new thread stalls for a few seconds. "Hello" is not emitted until some time passes, 1-5 seconds or so. 3. The new thread stalls for longer. I noticed that moving the mouse, or clicking, or pressing keys on the keyboard can have the effect on unstalling the new thread. This all seems like the main thread releases and reacquires the global lock too quickly, so the new thread has a very small window of opportunity to acquire it. Using thread-join unstalls the new thread because it causes the main thread to wait on a condition variable which releases the global lock until the condition is signalled. This gives plenty of opportunity for the new thread to acquire the global lock and progress. According to pthread_mutexattr(3) man page on macOS, phread_mutex_t was fair until macOS 10.14 (Mojave, released late 2018), when it became non-fair by default. So I guess the NS code was working just fine when it was tested on macOS back in the day. AFAIK, on GNU/Linux, pthread_mutex_t is non-fair and somehow this unfairness is more pronounced, at least for the NS use case. Thanks, Kaloian
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 3 Jan 2026 13:47:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 08:47:30 2026
Received: from localhost ([127.0.0.1]:34505 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vc1yc-0003mW-2S
for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 08:47:30 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:51822)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vc1yZ-0003mI-BL
for 80112 <at> debbugs.gnu.org; Sat, 03 Jan 2026 08:47:28 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vc1yT-0006VF-OX; Sat, 03 Jan 2026 08:47:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=4wOA95NKaAGQdi9AA8cvqLBRx2M5Wb4J2pa1KIP3WUo=; b=PHrnZ834N71sxTP2RV8J
8WSMJf0IBSW/Akv+Umi/TQvOsJ5p6GtrOny2xUHMnWHQrtdLnyzDmxzsd+8PFOak5jrDhvwky7Nz2
Sguy/MhRgvCgCeRv2NUrMpP3QMUqcMN0lBcbBRjF+vwg9U4tlxV5hHlgemnK9sBAlahAjoqE6ctaE
MLDlK1EUVSYmupV+MyFZr+xvvcQcDF8BQqoRfzs1rZhXoJ8ivTQALKyAYzTZa5izbg8dNkU50Igi4
VZjvooc/gNoI04XK0x5gCLHyeYE9ymNXNLdhYv1/orrxxkeYmfdfXpih4SiGD8uQw5Opw2D3aWkNI
kuLAl7j82U6Pkg==;
Date: Sat, 03 Jan 2026 15:47:19 +0200
Message-Id: <86h5t2kdug.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
In-Reply-To: <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor
Doganov on Sat, 03 Jan 2026 13:01:29 +0200)
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN>
<867bu0nqdt.fsf@HIDDEN> <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Sat, 03 Jan 2026 13:01:29 +0200
> From: Yavor Doganov <yavor@HIDDEN>
> Cc: kaloian@HIDDEN,
> 80112 <at> debbugs.gnu.org,
> yavor@HIDDEN,
> shipmints@HIDDEN
>
> > . make-thread creates a new thread that starts the thread function,
> > which attempts to acquire the global lock (see run_thread)
>
> This happens; the new thread attempts to acquire the global lock in
> run_thread.
>
> > . when the main thread, the one where the above form was evaluated,
> > becomes idle, and calls thread_select, it releases the global
> > lock (see really_call_select, which is called by thread_select),
> > at which point the new thread created above is expected to acquire
> > the global lock, run its Lisp code, then exit
>
> This doesn't happen -- the main thread releases the lock in
> really_call_select but acquires it back immediately.
The only way I could understand this is that the OS doesn't let the
other thread run, although it is waiting for the mutex and nothing
else.
Does the system's thread scheduler have some policy to prefer the
thread that was just preempted, and allow it to re-acquire the mutex
it just released, instead of giving the mutex to another thread?
And note that the main thread still has to call pselect after it
releases the mutex, whereas the other thread just waits for the mutex.
So this really is strange behavior of the thread scheduling.
> > . when the non-main thread exits, the main thread acquires the
> > global lock again
>
> The non-main thread never exits as it never manages to acquire the
> global lock; the main thread releases and acquires the lock
> periodically.
How can that happen?
> Note that merely adding the following printf statement in
> really_call_select right after the release_global_lock call
>
> printf ("really_call_select: global lock released: %s\n",
> (getpid () == gettid ()) ? "main thread" : "new thread");
>
> makes evaluating the expression to print "Hello" after 1-3 seconds
> delay which is an indication of some race condition/concurrency
> problem.
Which thread executes the printf?
> The following change (not really a fix) forces the main
> thread to yield after releasing the global lock and this gives a
> chance for the new thread to acquire it:
>
> diff --git a/src/thread.c b/src/thread.c
> index e8cf497a3a5..0f19acad765 100644
> --- a/src/thread.c
> +++ b/src/thread.c
> @@ -34,6 +34,8 @@ Copyright (C) 2012-2026 Free Software Foundation, Inc.
>
> #if defined HAVE_GLIB && ! defined (HAVE_NS)
> #include <xgselect.h>
> +#elif defined NS_IMPL_GNUSTEP
> +#define release_select_lock() sleep (0)
> #else
> #define release_select_lock() do { } while (0)
> #endif
>
> With this change, there is no bug ("Hello" appears immediately) and
> it's extremely easy to trigger the freeze described in Bug#80110. It
> happens when wait_reading_process_output (process.c) calls ns_select
> not from the main thread which then calls [NSApp run].
I believe someone already said that calling [NSApp run] from a
non-main thread is a no-no?
However, if {NSApp run] is needed to perform redisplay, we must run
it, or else a non-main thread will be unable to trigger redisplay.
> Stéphane Marks wrote:
> > So it's likely something else related to the Linux build with
> > GNUstep. Perhaps the user can verify the test on a Lucid or GTK
> > build.
>
> No, I cannot reproduce with a Lucid or GTK build (also tried Lucid
> configured with emacs_cv_links_glib=no to force it to use
> thread_select instead of xg_select).
But Stéphane said it was something specific to NS on GNU/Linux, not
something specific to GNU/Linux itself.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 3 Jan 2026 13:24:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 08:24:28 2026 Received: from localhost ([127.0.0.1]:34438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vc1cJ-0008JQ-ND for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 08:24:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54942) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vc1cG-0008J9-5G for 80112 <at> debbugs.gnu.org; Sat, 03 Jan 2026 08:24:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vc1cA-00067h-G1; Sat, 03 Jan 2026 08:24:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fB2/h8bCRUJo+eY57NsfFP/SJdfTfk1lyzqxPblxhXM=; b=WVpzXrbsncy0 yGQlRCPtbz73BzX3xEP7sWEAZh2DoPm3aBlfkCp5L5j+d6H4C9HCvJBWkGtk1duuQax/2iYbI0dML Yy6ZDET/+9JzeFQ/jFgPP05anWDoKjeimiwW0URNRS2niunXX7MCITFWU6Bcv9dZ6b/JYBQm4Gcza 6Mj2JmpYxxYNpzypsD68Ds6N8PtwzU5SSnPjJoVrCu83bSyw+rSUqp3EnUJfQQ2VZaGYPOrNYNtg5 sjAQJrnjXtstFais6xJG/c8yoypq0g9Vuq1UuoHvCrcIIQC29JdSGih0ZiztCB45XIzg+SVt5sqZG nThbfwFCkUx+sNvsRfmOJg==; Date: Sat, 03 Jan 2026 15:24:11 +0200 Message-Id: <86jyxykex0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Kaloian Doganov <kaloian@HIDDEN> In-Reply-To: <87v7hjhug1.wl-kaloian@HIDDEN> (message from Kaloian Doganov on Sat, 03 Jan 2026 12:17:02 +0200) Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> <87v7hjhug1.wl-kaloian@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80112 Cc: yavor@HIDDEN, 80112 <at> debbugs.gnu.org, shipmints@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 03 Jan 2026 12:17:02 +0200 > From: Kaloian Doganov <kaloian@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, > Yavor Doganov <yavor@HIDDEN>, > kaloian@HIDDEN, > 80112 <at> debbugs.gnu.org > > I just tried this with Emacs 30.1 on macOS 15.7.2 (Sequoia) with an M4 CPU. I > did multiple attempts and the example runs fine *sometimes*. I can classify the > behavior roughly in three different groups: > > 1. The example runs fine, the "Hello" message is emitted immediately by the new > thread. > > 2. The new thread stalls for a few seconds. "Hello" is not emitted until some > time passes, 1-5 seconds or so. > > 3. The new thread stalls for longer. > > I noticed that moving the mouse, or clicking, or pressing keys on the keyboard > can have the effect on unstalling the new thread. This means that there's some additional factor at work here, which affects how threads are scheduled. How many CPU execution units do you have on that system? And I assume the system was not heavily loaded when you ran these experiments? > This all seems like the main thread releases and reacquires the global lock too > quickly, so the new thread has a very small window of opportunity to acquire it. I don't see how this could be true. The "too quickly" part is not up to the thread, it's up to the system's scheduler. When one Lisp thread releases the global lock whether another thread, which is ready to run, will run and succeed to acquire the lock, is up to the OS, which implements the thread scheduling. That's because Emacs uses the "normal" system threads to implement Lisp threads. So whether the same main thread will immediately re-acquire the lock depends on whether the OS lets another thread run. We expect that to happen, and I would be very surprised if on some system it doesn't. If the OS does let another thread run, it will normally always grab t6he lock, because the main thread, which released the lock, has yet to call pselect and return from that call, before it attempts to re-acquire the lock. Whereas the other thread is expected to acquire the lock immediately as soon as the lock is released, since it was waiting for the lock to be released, and is otherwise ready to run. > According to pthread_mutexattr(3) man page on macOS, phread_mutex_t was fair > until macOS 10.14 (Mojave, released late 2018), when it became non-fair by > default. So I guess the NS code was working just fine when it was tested on > macOS back in the day. What does "non-fair" mean in this context? And how can we make the scheduler be "fair"?
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 3 Jan 2026 11:01:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 03 06:01:46 2026
Received: from localhost ([127.0.0.1]:33921 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vbzOC-0001sf-92
for submit <at> debbugs.gnu.org; Sat, 03 Jan 2026 06:01:45 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37942)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vbzOA-0001s9-BK
for 80112 <at> debbugs.gnu.org; Sat, 03 Jan 2026 06:01:42 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>)
id 1vbzO4-0007aZ-T6; Sat, 03 Jan 2026 06:01:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:References:In-Reply-To:Subject:To:From:
Date; bh=w1gcNsXxY2UwRKGkgRohbKe4nfie7A8Q6fxwe34KT+s=; b=Pw9olKYsoBcwK5KY1HBY
fN/2tXsobTZnUNtIcM2gOx7xMXpxdu9Ci5gwkzS2+04euxFXf8iYPkamQ9pdDqWykrGFo/KJoFemS
H2I20MEk2keIxUG1ZT8xDGKnn556Y57PxOKpwBDl+VIGHkQrGAQVrrvILItoIkaa6S1T3lHMsW04x
zxyzV4MBuS1HSSdpcHbpOZxlNhHGsVz3xGAw3vNC8lzLYSCkM7vG86MPlTgAsh29b3BKtlXay0I7k
at2weEPeHOOHcvxs1YpPz4zImJ0r+FqKyl5CKZm5HgfrzYx4IjnDpy+zeLDpsFr3nxtVsUD8pTEPe
tpDW6MLhEANB0Q==;
Date: Sat, 03 Jan 2026 13:01:29 +0200
Message-ID: <871pk7arjq.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
In-Reply-To: <867bu0nqdt.fsf@HIDDEN>
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2
(x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, 80112 <at> debbugs.gnu.org, yavor@HIDDEN,
shipmints@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Eli Zaretskii wrote:
> > Evaluating the expression
> >
> > (make-thread
> > (lambda ()
> > (message "Hello")
> > "World"))
> What is expected to happen here is the following:
Thanks; your explanation was very helpful.
> . make-thread creates a new thread that starts the thread function,
> which attempts to acquire the global lock (see run_thread)
This happens; the new thread attempts to acquire the global lock in
run_thread.
> . when the main thread, the one where the above form was evaluated,
> becomes idle, and calls thread_select, it releases the global
> lock (see really_call_select, which is called by thread_select),
> at which point the new thread created above is expected to acquire
> the global lock, run its Lisp code, then exit
This doesn't happen -- the main thread releases the lock in
really_call_select but acquires it back immediately.
> . when the non-main thread exits, the main thread acquires the
> global lock again
The non-main thread never exits as it never manages to acquire the
global lock; the main thread releases and acquires the lock
periodically.
Note that merely adding the following printf statement in
really_call_select right after the release_global_lock call
printf ("really_call_select: global lock released: %s\n",
(getpid () == gettid ()) ? "main thread" : "new thread");
makes evaluating the expression to print "Hello" after 1-3 seconds
delay which is an indication of some race condition/concurrency
problem. The following change (not really a fix) forces the main
thread to yield after releasing the global lock and this gives a
chance for the new thread to acquire it:
diff --git a/src/thread.c b/src/thread.c
index e8cf497a3a5..0f19acad765 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -34,6 +34,8 @@ Copyright (C) 2012-2026 Free Software Foundation, Inc.
#if defined HAVE_GLIB && ! defined (HAVE_NS)
#include <xgselect.h>
+#elif defined NS_IMPL_GNUSTEP
+#define release_select_lock() sleep (0)
#else
#define release_select_lock() do { } while (0)
#endif
With this change, there is no bug ("Hello" appears immediately) and
it's extremely easy to trigger the freeze described in Bug#80110. It
happens when wait_reading_process_output (process.c) calls ns_select
not from the main thread which then calls [NSApp run].
Stéphane Marks wrote:
> So it's likely something else related to the Linux build with
> GNUstep. Perhaps the user can verify the test on a Lucid or GTK
> build.
No, I cannot reproduce with a Lucid or GTK build (also tried Lucid
configured with emacs_cv_links_glib=no to force it to use
thread_select instead of xg_select).
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.Received: (at 80112) by debbugs.gnu.org; 2 Jan 2026 12:51:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 07:51:20 2026 Received: from localhost ([127.0.0.1]:56729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vbeci-0005OY-7C for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:51:20 -0500 Received: from mail-vk1-xa2c.google.com ([2607:f8b0:4864:20::a2c]:59853) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vbecf-0005OK-2O for 80112 <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:51:18 -0500 Received: by mail-vk1-xa2c.google.com with SMTP id 71dfb90a1353d-55ad466ad1eso2981585e0c.3 for <80112 <at> debbugs.gnu.org>; Fri, 02 Jan 2026 04:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767358276; x=1767963076; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dkBSN2l4vvQU7LzWjBOabwzwz9nG1evXqClquNbHdOc=; b=PGIEbojECMsau31lB71xocX7lzYaXyMJjHB7T3Z8ag5Jx4cgcjFHlDlYc9BWpnE0Y9 QAcTWEj1mJs4WHTAjBseXr/No9ApJgFmP1tZALw3saOrd93XviSBKuFdfU2gZMbmFhtp QSe7i3e8b6dYf7fuVeG/lmVEZXKAOQYHdaadFvt5fC5ZMkxb1jAxipVPZeLSv+qUR55I 8EfFFMcs4edX24oajnzihtZdWY1SPUgrey2r4iIt3Spd/e3VNqzXIO4GNqAupJ9acY/d PUvVLwAFGCvxZU/KxBJn2QjylYnMZAXulsQOKdn864mZy1ucllf4sxlUnnhfAf/YBEGg jNHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767358276; x=1767963076; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dkBSN2l4vvQU7LzWjBOabwzwz9nG1evXqClquNbHdOc=; b=BwajJwoz4vzef4W2TkHIrfvHD2jnduDgg3QUbUBvTDp0Fwdjcq96c61VyJy8SjPZVV DlzRWtUvCf9afcbLaXrKaMej3wx1QhTSD7/YHRUn/7hwDKR1Wo0k2du9NOY2PaQPyImi BqbPrTm/Vi135CW8m+CIYSn/OKkA+uueLR6pIfA3GH0+H7Za2XnKTRK80cc6qrxDkRnr gs1s5V55IKSb2/KJTdAKIsQKWUhR0j/OU4j2dxOhGFQFOO7sZrmTLiYP4AV+xFYm+HZD LFtGLnVs/nyHmIGK40SeYg87vX2a8GDz20T0RxHYD2Jx7t8IgB1OcjLevooA1dUYKH1X 1AqQ== X-Forwarded-Encrypted: i=1; AJvYcCWhv1QHf4bqw2P/dfhnW88q7IsDbmuIxiZ4qfYEw1B/07S1/btxhtVr9nqfiAjKCds7fWhTMw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxve+1fo6mmJZGwMuvLUQBVykAVH0Qw79ye7DBKJW0lkhquQp7b jRNeDd+T1kIR9e/Cl+hSk1p8Pmg5Xk8+HvCBrW3pXIWVnzmTgmsT9+fek118WiYBHAWQtvshqhl nrwFDXo3srUEGcn7rMMVgVqX+LmbPo98T9Q== X-Gm-Gg: AY/fxX5Ly/LdMBRHaf3cvQ/2tAyiNFc620zrjqfQ1YiOOCpzAPSrIQX2TGArzNDDqaj We0Vb4p2FNopDwYZNfMLIbkQToss27iImHt2ENG5xRI5+Sjqz5VKSqbkgWl1mOeljm8WzJA1Pmb s6nWy5Z15FRsKCFsNyKcv31emHLYvvw/UAq2aheU7oLiVrnLj/6b/2qBl3YfdHdtu+RiJ89ZKF7 +k75Fk0b04Yqj5HV4hdKFPfFYKkJql0mLmKp4ceVDBuajCe7H/PjGXrGHZYx6y0YZDxIgo= X-Google-Smtp-Source: AGHT+IF02TzTQ1otnZf8hAFYV/LTLDjXGN6pU7XfPYrkdBOXt21R/K9pfYrsNLYx5Qz0kBx3/nqqoCJqHGVs9s/g5UE= X-Received: by 2002:a05:6122:2a03:b0:557:4110:6b97 with SMTP id 71dfb90a1353d-5615be02e30mr10831584e0c.12.1767358276267; Fri, 02 Jan 2026 04:51:16 -0800 (PST) MIME-Version: 1.0 References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> <867bu0nqdt.fsf@HIDDEN> In-Reply-To: <867bu0nqdt.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Fri, 2 Jan 2026 07:51:04 -0500 X-Gm-Features: AQt7F2robDmcGhEH-i2pv0zXy9mwqkl_4OUKShcTS7GPsBG04c5cmNeUkLDW4ts Message-ID: <CAN+1HbqX_0SOxSDXsCFxfEjtDzKP44=KyBMdqS722ODuHK0M7A@HIDDEN> Subject: Re: bug#80112: 31.0.50; NS; make-thread creates a new thread but doesn't start it To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000003f707f0647672a3d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 80112 Cc: Yavor Doganov <yavor@HIDDEN>, 80112 <at> debbugs.gnu.org, kaloian@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000003f707f0647672a3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 2, 2026 at 7:38=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote: > > Cc: yavor@HIDDEN, kaloian@HIDDEN > > Date: Fri, 02 Jan 2026 13:33:29 +0200 > > From: Yavor Doganov <yavor@HIDDEN> > > > > Evaluating the expression > > > > (make-thread > > (lambda () > > (message "Hello") > > "World")) > > > > gives > > > > #<thread 0x558d32a9a2f8> > > I cannot reproduce this, so I guess this is specific to NS or > something. Debugging of this problem would be welcome. > > What is expected to happen here is the following: > > . make-thread creates a new thread that starts the thread function, > which attempts to acquire the global lock (see run_thread) > . when the main thread, the one where the above form was evaluated, > becomes idle, and calls thread_select, it releases the global > lock (see really_call_select, which is called by thread_select), > at which point the new thread created above is expected to acquire > the global lock, run its Lisp code, then exit > . when the non-main thread exits, the main thread acquires the > global lock again > > > The bug is not present when I start Emacs with -nw. > > Which probably means the NS GUI code somehow breaks this. > The example works fine for me on macOS for both 30.2 and a fresh master build. So it's likely something else related to the Linux build with GNUstep. Perhaps the user can verify the test on a Lucid or GTK build. --0000000000003f707f0647672a3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Fri, Jan 2, 2026 at 7:38=E2=80=AFAM Eli Zaretskii <<a href=3D"mailto:= eliz@HIDDEN">eliz@HIDDEN</a>> wrote:</span></div></div><div class=3D"g= mail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">> Cc: <a href=3D"mailto:yavor@HIDDEN" target=3D"_blank">yavo= r@HIDDEN</a>, <a href=3D"mailto:kaloian@HIDDEN" target=3D"_blank">kal= oian@HIDDEN</a><br> > Date: Fri, 02 Jan 2026 13:33:29 +0200<br> > From: Yavor Doganov <<a href=3D"mailto:yavor@HIDDEN" target=3D"_bl= ank">yavor@HIDDEN</a>><br> > <br> > Evaluating the expression<br> > <br> > (make-thread<br> >=C2=A0 (lambda ()<br> >=C2=A0 =C2=A0 (message "Hello")<br> >=C2=A0 =C2=A0 "World"))<br> > <br> > gives<br> > <br> > #<thread 0x558d32a9a2f8><br> <br> I cannot reproduce this, so I guess this is specific to NS or<br> something.=C2=A0 Debugging of this problem would be welcome.<br> <br> What is expected to happen here is the following:<br> <br> =C2=A0 . make-thread creates a new thread that starts the thread function,<= br> =C2=A0 =C2=A0 which attempts to acquire the global lock (see run_thread)<br= > =C2=A0 . when the main thread, the one where the above form was evaluated,<= br> =C2=A0 =C2=A0 becomes idle, and calls thread_select, it releases the global= <br> =C2=A0 =C2=A0 lock (see really_call_select, which is called by thread_selec= t),<br> =C2=A0 =C2=A0 at which point the new thread created above is expected to ac= quire<br> =C2=A0 =C2=A0 the global lock, run its Lisp code, then exit<br> =C2=A0 . when the non-main thread exits, the main thread acquires the<br> =C2=A0 =C2=A0 global lock again<br> <br> > The bug is not present when I start Emacs with -nw.<br> <br> Which probably means the NS GUI code somehow breaks this.<br></blockquote><= div><br></div><div class=3D"gmail_default" style=3D"font-family:monospace">= The example works fine for me on macOS for both 30.2 and a fresh master bui= ld.=C2=A0 So it's likely something else related to the Linux build with= GNUstep.=C2=A0 Perhaps the user can verify the test on a Lucid or GTK buil= d.=C2=A0</div></div></div> --0000000000003f707f0647672a3d--
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at 80112) by debbugs.gnu.org; 2 Jan 2026 12:36:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 07:36:17 2026
Received: from localhost ([127.0.0.1]:56674 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vbeO8-0004cE-S8
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:36:17 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:36110)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vbeO5-0004bj-DE
for 80112 <at> debbugs.gnu.org; Fri, 02 Jan 2026 07:36:15 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vbeNz-0005XN-Eh; Fri, 02 Jan 2026 07:36:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=m7KtX7qKKtFfwRXGxgkEyfuOLG7P5NTqNdQ2NaDSYKg=; b=UKicNk+0eJxc
d6lMJq0tOhPApZ1zrbLcbndWWtYR2Qtr/zAIc8zHVF91uepZzMSKcHogwwtZJ5Tu6jnZfgXXFQnmZ
MapAZN56YyV6O2OZS86Z1s7tHuUHa9fdycQsbMsj9qblPiOGEiYITkR/nN6bhkY0GGEAo2khB7qHX
NSB8LqPMWnLV0nwgyVLQp+IjnMnu9x5K001WDTLyGL4t3PqVIzPujPgVRa4yovNzAGDDFxwbzM9CJ
bPKKABEnhcZzQkwaPa129J3WD173ocVKL62aYm0n6Hd6D0whNze+/Yr0HLzVJwlEtdekpT6JiJRY9
hVz6rcc1IoTgXx1cuNaGeg==;
Date: Fri, 02 Jan 2026 14:35:58 +0200
Message-Id: <867bu0nqdt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Yavor Doganov <yavor@HIDDEN>
In-Reply-To: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN> (message from Yavor
Doganov on Fri, 02 Jan 2026 13:33:29 +0200)
Subject: Re: bug#80112: 31.0.50; NS;
make-thread creates a new thread but doesn't start it
References: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80112
Cc: kaloian@HIDDEN, 80112 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: yavor@HIDDEN, kaloian@HIDDEN
> Date: Fri, 02 Jan 2026 13:33:29 +0200
> From: Yavor Doganov <yavor@HIDDEN>
>
> Evaluating the expression
>
> (make-thread
> (lambda ()
> (message "Hello")
> "World"))
>
> gives
>
> #<thread 0x558d32a9a2f8>
I cannot reproduce this, so I guess this is specific to NS or
something. Debugging of this problem would be welcome.
What is expected to happen here is the following:
. make-thread creates a new thread that starts the thread function,
which attempts to acquire the global lock (see run_thread)
. when the main thread, the one where the above form was evaluated,
becomes idle, and calls thread_select, it releases the global
lock (see really_call_select, which is called by thread_select),
at which point the new thread created above is expected to acquire
the global lock, run its Lisp code, then exit
. when the non-main thread exits, the main thread acquires the
global lock again
> The bug is not present when I start Emacs with -nw.
Which probably means the NS GUI code somehow breaks this.
Thanks.
bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 2 Jan 2026 11:34:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 02 06:34:12 2026
Received: from localhost ([127.0.0.1]:56499 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vbdQ3-00075y-Oc
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 06:34:12 -0500
Received: from lists.gnu.org ([2001:470:142::17]:48942)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yavor@HIDDEN>) id 1vbdQ0-00075i-TG
for submit <at> debbugs.gnu.org; Fri, 02 Jan 2026 06:34:09 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vbdPt-0007xd-TX
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2026 06:34:02 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yavor@HIDDEN>) id 1vbdPt-0001W7-LO
for bug-gnu-emacs@HIDDEN; Fri, 02 Jan 2026 06:34:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Subject:To:From:Date:in-reply-to:
references; bh=aH0Zb4vf1tjSX2f9BmRurZFwbeOVi9gfqjjWOQMd4P0=; b=qodazNl50uY/hA
vmQsa1Ziy+FwgS1XCXjeOj195BPQhdTS98rSqZEMIE1yiIc5aI66x8zrhGmms5qW7paFRlj1EHwNF
qIo7vM404XqLHN+EmO2ja2H2XcXr0l/jSrW9NIB12VlECrfc/QW2HQdqjhLpA9p9no34640XSgo1P
86EdEeqGI1BslKQ6IAKMTwOC42DVRt6jaDKv8fmw69lDOxA6HQrzrUtgAwbSZFsFkCUxdOoWFooEM
YotovEQOnlsRHFlOqwj2RqohhooTW4Q69Fb2Kk/YH5LBjl5LZTS1nO/8k+0bQEOcXEgy2b9E2mZ6k
a7/ByG+WPIhmDO7xnsaQ==;
Date: Fri, 02 Jan 2026 13:33:29 +0200
Message-ID: <871pk8qmeu.GNU's_not_UNIX!-yavor@HIDDEN>
From: Yavor Doganov <yavor@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; NS; make-thread creates a new thread but doesn't start it
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2
(x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
X-Debbugs-Cc: yavor@HIDDEN, kaloian@HIDDEN
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Evaluating the expression
(make-thread
(lambda ()
(message "Hello")
"World"))
gives
#<thread 0x558d32a9a2f8>
If I force execution with thread-join, like
(thread-join
(make-thread
(lambda ()
(message "Hello")
"World")))
I get
Hello [2 times]
"World"
The bug is not present when I start Emacs with -nw.
In GNU Emacs 31.0.50 (build 14, x86_64-pc-linux-gnu, NS
gnustep-gui-0.32.0) of 2026-01-02 built on patilan
Repository revision: 1e777f71f23761469c31d29faddb10a35177848c
Repository branch: master
Windowing system distributor 'GNU', version 10.3.32
System Description: Debian GNU/Linux forky/sid
Configured using:
'configure --with-ns'
Configured features:
ACL DBUS GIF GLIB GMP GNUTLS GPM JPEG LCMS2 LIBSELINUX LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY NS PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB
Yavor Doganov <yavor@HIDDEN>:yavor@HIDDEN, kaloian@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.yavor@HIDDEN, kaloian@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80112; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.