From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#30182: Update Date: Wed, 24 Jan 2018 09:39:38 +0100 Message-ID: <5A68464A.1060703@gmx.at> References: <87k1wdqc4q.fsf@gmail.com> <87inbxqc1l.fsf@gmail.com> <5A631B7F.3030308@gmx.at> <878tcs3j23.fsf@gmail.com> <5A634E53.7010205@gmx.at> <87mv182bzk.fsf@gmail.com> <83a7x7sww6.fsf@gnu.org> <87efmj27d5.fsf@gmail.com> <83vafvqjbf.fsf@gnu.org> <87inbvxdz8.fsf@gmail.com> <5A65AB97.1030401@gmx.at> <87po62kk10.fsf@gmail.com> <831sih23rh.fsf@gnu.org> <5A663490.3050409@gmx.at> <87r2qh5lya.fsf@gmail.com> <83po60zgyf.fsf@gnu.org> <877es8cxmv.fsf@gmail.com> <83fu6wo5bd.fsf@gnu.org> <5A6782A5.8040808@gmx.at> <834lncny6z.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1516783112 13240 195.159.176.226 (24 Jan 2018 08:38:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 24 Jan 2018 08:38:32 +0000 (UTC) Cc: m.sujith@gmail.com, 30182@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 24 09:38:28 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeGZW-0002bO-Iq for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jan 2018 09:38:18 +0100 Original-Received: from localhost ([::1]:34275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eeGbW-00078f-W1 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jan 2018 03:40:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eeGbJ-00073y-26 for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 03:40:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eeGbD-0001DH-QR for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 03:40:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60699) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eeGbD-0001Ce-Im for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 03:40:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eeGbD-00024S-9d for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 03:40:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jan 2018 08:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30182 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30182-submit@debbugs.gnu.org id=B30182.15167831947926 (code B ref 30182); Wed, 24 Jan 2018 08:40:03 +0000 Original-Received: (at 30182) by debbugs.gnu.org; 24 Jan 2018 08:39:54 +0000 Original-Received: from localhost ([127.0.0.1]:40361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeGb3-00023m-SQ for submit@debbugs.gnu.org; Wed, 24 Jan 2018 03:39:54 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:54401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeGb1-00023Z-Te for 30182@debbugs.gnu.org; Wed, 24 Jan 2018 03:39:52 -0500 Original-Received: from [192.168.1.100] ([46.125.250.48]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LfTC1-1f7L5c3dHN-00p5EL; Wed, 24 Jan 2018 09:39:45 +0100 In-Reply-To: <834lncny6z.fsf@gnu.org> X-Provags-ID: V03:K0:D4XL9KZNw09M642fy6WM6K86FwFqqW9Cjwg0+22bCgmUB1wPwVo 6+bBPYLWnb2dOplpwO23z5goz4lHsrss/nJYyVKBSlCHimp+18VMFBlR9WE7yKA9iD0nyPM SGLdJcC7+P9fmp/UsnetqU9XuAfrKGPlLrPzx2rE8NsEKJNITLkq6p1rua5ovtzqFlxHbNm 09mLdHuZINndt2rDVMBbw== X-UI-Out-Filterresults: notjunk:1;V01:K0:qxOuc0Ey95A=:FLLMTtZ0mAOfcBIQU9PrSm //WEa5Qh9j7559ItBn+ATUbcfwqpBamYG8iapCCMJx7rYdXcVnWrfrNzA4YPqwVBtJrB/7BPM is35LcEx3vbjCOxLaQymNn09K9HbQDRORboUrRc4ihOBNR154RHEk7GUhY2Wfh6OUeLGDvXAG leaDEEAQHShToc4ghgMtOlnPYBkloO/ZtrbIwbOP4bAt4e4acNGLXHZDZvydrn2CIGWgpJT/G wQS87sG12Qdm+UuRihxjhUO8chyzcHQECqvfAWnEAXutr3l9ufV4NkssWIH6/btjD2ZZ6cr7K k4QyslC3AHo2sezyK9enEY2naRd9v7RlKuNL+HLIOWmuQNP+FI0e5kMj++nSMPZV19mUalodo tZZR+RZqLfklc8i/fH4HlOeISoeKMtMtRh3xkTPwMT4Lsu/zHoDcOt6DF0AVkYczNHJ2AlTBB 9Y1yFa1UsoVMexhITk9A6UezvCJs1I59e5OLHGQcRM3qAlD+0MnFjEa1BaykdXsW8FA6FLbU+ yhhU+rhLmChPrs7pZzLEylKfnDWn+yZBkcPMXp5z8uNeLTlQj9CQmCgRciJ3JVKgljbYuhca+ wMHmYGEnZ61w8sRZfqy2inBMTwm5SrXWw3Tc9nfoBaV9gTNsn4EJfx+IOsjqMhyvTdtn/3pBX SYIWVpxtmk1gA8Da6KlwlP0JqbIO1MOHXF4/MlDJr2CHZ7yEbP1beedtHqIKHMLUrhPwaYh/S HjIcryjNyi4dRnSXERcqZ1m0Wu2Pnb9rhJm34BqtnNSZ+aHDw373MDgPC7+KHMKLeUQenrDT 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: 208.118.235.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:142463 Archived-At: >> We don't know whether `timer-list' had actually 5 elements when >> running the above code. > > If it didn't, then the 5th element could have only been added by > another thread. Why another thread? > Is that possible? This is a GTK build with system > tooltips, right? And even in such a configuration the tooltips are > popped up in the context of the main thread, is that so? So how could > the list be modified while copy-sequence runs? > >> And Fmake_list can rarely_quit. > > Not sure how quitting in Fmake_list could explain anything. If it > quits, it just throws to top-level, and that's all, right? Fmake_list does for (EMACS_INT size = XFASTINT (length); 0 < size; size--) { val = Fcons (init, val); rarely_quit (size); } so IIUC rarely_quit is eventually called with size zero. Now we have rarely_quit (unsigned short int count) { if (! count) maybe_quit (); which, if count is zero, calls maybe_quit which according to if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) process_quit_flag (); else if (pending_signals) process_pending_signals (); may call process_pending_signals which does do_pending_atimers (); which may eventually do a schedule_atimer. So IMHO the problem is not that rarely_quit "just throws to top-level" but might add a timer on the fly while the timer list is copied. martin