From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25214: 26.0.50; Interacting with user from threads other than the primary Date: Fri, 16 Dec 2016 17:17:02 +0200 Message-ID: <837f6z9a4x.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1481901556 15170 195.159.176.226 (16 Dec 2016 15:19:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 15:19:16 +0000 (UTC) Cc: Tom Tromey To: 25214@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 16 16:19:12 2016 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 1cHuHv-0002rg-7V for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Dec 2016 16:19:11 +0100 Original-Received: from localhost ([::1]:32791 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHuHz-00069N-HZ for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 Dec 2016 10:19:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHuHr-0005uF-Tk for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2016 10:19:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHuHm-0008E9-Ro for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2016 10:19:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57271) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cHuHm-0008E4-OC for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2016 10:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cHuHm-0001Hk-K8 for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2016 10:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2016 15:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 25214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.14819015034892 (code B ref -1); Fri, 16 Dec 2016 15:19:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 16 Dec 2016 15:18:23 +0000 Original-Received: from localhost ([127.0.0.1]:44437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHuH9-0001Gq-7N for submit@debbugs.gnu.org; Fri, 16 Dec 2016 10:18:23 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34609) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHuH7-0001Ge-Ha for submit@debbugs.gnu.org; Fri, 16 Dec 2016 10:18:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHuH1-00083N-0Z for submit@debbugs.gnu.org; Fri, 16 Dec 2016 10:18:16 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:55813) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cHuH0-00083J-TW for submit@debbugs.gnu.org; Fri, 16 Dec 2016 10:18:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHuGz-0003Oa-Df for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2016 10:18:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHuGu-000825-EU for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2016 10:18:13 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHuGY-0007w8-9l; Fri, 16 Dec 2016 10:17:46 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2799 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cHuGX-0008Ez-9E; Fri, 16 Dec 2016 10:17:46 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:127092 Archived-At: Here's some fun with threads: emacs -Q Evaluate: (defun my-question () (let (use-dialog-box) ;; in case this is a GUI frame (if (y-or-n-p "Yes or no? ") (message "You said YES") (message "You said NO")))) Evaluate: (my-question) You get a question asked in the minibuffer, answer it with Y or N, and get the corresponding echo. All's well. Now evaluate this: (make-thread #'my-question "question") You again get the question asked in the minibuffer, but typing anything at the prompt causes Emacs to complain that whatever you typed is "undefined". Your only fire escape is to close this session with some mouse gesture, or kill it. What happens here is that, by the time the new thread runs, the main (a.k.a. "primary") thread is already idle, i.e. it already called read_char, which called wait_reading_process_output, which called thread_select. (In fact, it's _because_ the primary thread called thread_select that the new thread was allowed to run at all, since it has to acquire the global lock for that, and that is only possible when the running thread releases the lock inside thread_select.) Now, when wait_reading_process_output calls thread_select, it prepares the mask for file descriptors it will wait for to become ready for reading, in this case there's only one descriptor: the keyboard descriptor. So the primary thread is waiting for input from the keyboard. Now the new thread starts running and eventually calls y-or-n-p, which calls read_char, which calls wait_reading_process_output. But when this call prepares the mask for the thread_select call, it skips the keyboard descriptor, because we only allow a single thread to wait on each descriptor, and the keyboard descriptor is already watched by the primary thread. So the new thread ends up not waiting on the keyboard input descriptor. The thread_select call then switches back to the primary thread, and the primary thread receives the Y or N character you type. But it doesn't know what to do with it, so it becomes confused. IOW, user interaction from non-primary threads is currently inherently unsafe. And then, of course, there's the use case where two threads ask the user something via the minibuffer. Thoughts? In GNU Emacs 26.0.50.118 (i686-pc-mingw32) of 2016-12-16 built on HOME-C4E4A596F7 Repository revision: fb2fdb1435d2520c1cbf2a3d6a53128512a38458 Windowing system distributor 'Microsoft Corp.', version 5.1.2600 Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int --with-modules 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS MODULES Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify w32 multi-tty make-network-process emacs) Memory information: ((conses 16 102990 12105) (symbols 56 21101 0) (miscs 48 36 129) (strings 16 21030 4737) (string-bytes 1 593607) (vectors 16 14398) (vector-slots 8 444812 4412) (floats 8 179 129) (intervals 40 269 104) (buffers 864 11))