From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Micha=C5=82?= Krzywkowski Newsgroups: gmane.emacs.bugs Subject: bug#37892: 27.0.50; Crash when signaling a thread Date: Sun, 27 Oct 2019 20:26:43 +0100 Message-ID: <8736feyop8.fsf@zoho.com> References: <87zhhro0gt.fsf@gmail.com> <83sgnhw6xr.fsf@gnu.org> <87blu3lmfc.fsf@gmail.com> <8336ffvf1p.fsf@gnu.org> <878sp6wl24.fsf@gmail.com> <83r22ys4kh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="84871"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.0; emacs 26.3.50 Cc: 37892@debbugs.gnu.org, =?UTF-8?Q?Micha=C5=82?= Krzywkowski To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 27 20:28:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iOoD3-000Lz9-Rk for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 20:28:17 +0100 Original-Received: from localhost ([::1]:46822 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOoD2-0007Lo-4b for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 15:28:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40570) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOoCr-0007GF-8f for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 15:28:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOoCq-0008LX-5A for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 15:28:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34732) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOoCq-0008LT-2c for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 15:28:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iOoCp-0000Yo-U1 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 15:28:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Micha=C5=82?= Krzywkowski Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2019 19:28:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37892 X-GNU-PR-Package: emacs Original-Received: via spool by 37892-submit@debbugs.gnu.org id=B37892.15722044222066 (code B ref 37892); Sun, 27 Oct 2019 19:28:03 +0000 Original-Received: (at 37892) by debbugs.gnu.org; 27 Oct 2019 19:27:02 +0000 Original-Received: from localhost ([127.0.0.1]:43553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOoBq-0000X6-C7 for submit@debbugs.gnu.org; Sun, 27 Oct 2019 15:27:02 -0400 Original-Received: from sender4-pp-o94.zoho.com ([136.143.188.94]:25463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOoBo-0000Wr-M7 for 37892@debbugs.gnu.org; Sun, 27 Oct 2019 15:27:01 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1572204414; cv=none; d=zohomail.com; s=zohoarc; b=JejLpM6QGkcbXT5izcy2DLssKV49aSQUWc6BjOoFcLtu/6Kft4C3uW4lsuVm3WO3cM94Cmhn66lTWlikd5BOT03iLZQU7rLDDpYqc8DnK9/jlkQvDY9wTgd6F56QYBaRiAN+uJn9E4BzbByJ4rfhM3wYG895uyIgUNDyfhpngXs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1572204414; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Sender:Subject:To; bh=KB9oQzqXpE9VSSDGYZ7oPPvI6OiaDtfnQlX+IRDhW7U=; b=FoRpQOb9ZTiM8T0beX1NvA57SBxoz1Kg7FpjdsnES2lDDFNof+lTX2TrAhap3SjmU6HAl9UldyPuJBc13Nn2qCx3wNvxLLXbBoEKB/3+4bB4PW9x0AlG6JHWrKIya1BsB8mCG15UwphXY3oGFPpacaPMjjPafo4e7XMOCQgYGyw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=gmail.com; spf=pass smtp.mailfrom=k.michal@zoho.com; dmarc=pass header.from= header.from= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=references:user-agent:from:to:cc:subject:in-reply-to:date:message-id:mime-version:content-type:sender; b=a4Wt+gicHgGbXjcoZYMjyjSj9jCqUp27YD0XUYoZH1RthiL2qaDPB9Ga7mEqbxCx7V/EZXctoFJy 0xeV6xQ2MMx6l0b+5aq8Zlilt0VtSeDvMtuMr6FL+4QYoc84I3NU Original-Received: from debian (89-65-39-79.dynamic.chello.pl [89.65.39.79]) by mx.zohomail.com with SMTPS id 1572204412304474.17981881179776; Sun, 27 Oct 2019 12:26:52 -0700 (PDT) In-reply-to: <83r22ys4kh.fsf@gnu.org> X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170269 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>>>> "Eli" =3D=3D Eli Zaretskii writes: Eli> But thread-signal is not for causing an error in a thread, it is f= or Eli> unblocking a thread that waits on a mutex or a condvar. So why wo= uld Eli> you use it when the thread is not blocked? >> >> Then I think documentation for that function should be changed to >> explicitly say that the signal will *only* be delivered if the target >> thread is in a "blocked call to =E2=80=98mutex-lock=E2=80=99, =E2=80= =98condition-wait=E2=80=99, or >> =E2=80=98thread-join=E2=80=99". >> >> Currently, the docstring of thread-signal just says that the function >> will interrupt threads which are blocked, but does not actually say = that >> the signal will be delivered only in those cases. In fact, it says = that >> it works like signal, so I don't think it's unreasonable to assume t= hat >> it will just interrupt a thread whatever it's doing. Eli> The function does work like a signal, but Emacs cannot be interrup= ted Eli> while it waits for input. In all other cases your signal will be Eli> delivered, and if unhandled, it will terminate the thread. Eli> If we decide that thread-signal will have no effect while a thread Eli> waits for input, then we will document that, of course. My questi= on Eli> was meant to understand your intent for signaling a thread at Eli> arbitrary time, because the effect of that is unpredictable, even = if Eli> the crash didn't happen. I wanted to understand your thinking and Eli> rationale, so as to have a better basis for the decision of how to= fix Eli> this problem. Eli> So could you please elaborate on your rationale? Actually there is no deeper reason behind it. I was just testing threads in Emacs, seeing how things behave. I certainly would think twice before writing code that interrupts a thread at an arbitrary point in a real program. When it comes to sit-for, I use it sometimes. Is there a reason not to use it in threads? In any case, I'm not encouraging anyone to program like that, I'm just reporting a crash... =2D- Micha=C5=82 Krzywkowski PGP: A5A7 06C4 28EF 8F64 2868 13A1 7BDE C129 F0B8 09A1 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEWxyvIOWnapfz9K2Z20CneWXMPiIFAl2173MACgkQ20CneWXM PiItyQf/XUCbgk2oQlkbuCHC5jcMofcQmT6ieV/0xxnwzYcklBFchXmyTeEHq8m0 E97bHXgUXHrhbm06IDuYitKQtIuYFxHxTTct6U9boE32r+mit8IXHDNVvFXK16mb APHnY/75xF+gc7ivHZazh6RYKYfvWm9BruVeu7ZSYhcnYmlc1U5ns0T/hpqKF5ZH 68o8M/oZJAAS0dSXWrhx0M+o0wqJAWHQr67+3jCY8V5RuTHpilEF+dDtbg83mgD6 ewIjc3tmDKG1ts4iIpEE/8Wckg0VPp80+Hg0oF7AMpZor4yZ83014eRHvs0ggJho pzmPrrgbtTdX8DEW8tznTvt0GO3lew== =ESb2 -----END PGP SIGNATURE----- --=-=-=--