From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: the state of the concurrency branch Date: Tue, 27 Aug 2013 19:08:21 +0300 Message-ID: <83mwo3f762.fsf@gnu.org> References: <87vc2t7erx.fsf@fleche.redhat.com> <83txicffpe.fsf@gnu.org> <87haeb3lwp.fsf@fleche.redhat.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1377619758 21351 80.91.229.3 (27 Aug 2013 16:09:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 16:09:18 +0000 (UTC) Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 27 18:09:20 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VELpU-0007Ti-Ik for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2013 18:09:16 +0200 Original-Received: from localhost ([::1]:57388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VELpU-0002ol-4S for ged-emacs-devel@m.gmane.org; Tue, 27 Aug 2013 12:09:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VELpM-0002nf-65 for emacs-devel@gnu.org; Tue, 27 Aug 2013 12:09:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VELpG-0007fM-4i for emacs-devel@gnu.org; Tue, 27 Aug 2013 12:09:08 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VELpF-0007fF-O5 for emacs-devel@gnu.org; Tue, 27 Aug 2013 12:09:02 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MS700D0064JLE00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 27 Aug 2013 19:08:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MS700D6565JC080@a-mtaout20.012.net.il>; Tue, 27 Aug 2013 19:08:08 +0300 (IDT) In-reply-to: <87haeb3lwp.fsf@fleche.redhat.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163050 Archived-At: > From: Tom Tromey > Cc: Eli Zaretskii , Juanma Barranquero , > emacs-devel@gnu.org > Date: Mon, 26 Aug 2013 20:30:46 -0600 > > The basic issue is that only one thread can select on a given fd at a > time. This means we have to track which threads are currently selecting > on which fds; and also it means we must recompute the various select > masks dynamically. What about the keyboard fd? is it selected by all threads, or just by some? If the latter, by which one(s)? Also, what about the special inputs, such as file notifications etc., which currently just stuff some events into the keyboard queue -- how, if at all, shall that change when more than one thread could be running and watching those events? And a related question: what about triggering redisplay, which is done as part of waiting for some input -- will it be triggered by more than one thread now? > Stefan> --- src/lisp.h 2013-08-25 20:25:59 +0000 > Stefan> +++ src/lisp.h 2013-08-26 21:03:23 +0000 > Stefan> @@ -535,6 +535,7 @@ > Stefan> ptrdiff_t size; > Stefan> }; > > Stefan> +/* FIXME: Including thread.h here is odd, we normally don't do that. */ > Stefan> #include "thread.h" > > Yeah. The ordering is funky due to the #define hack. It was the main reason for breaking the Windows compilation, btw. We have now an unfortunate situation whereby lisp.h cannot be included before some of the other headers, due to this. > Stefan> +/* FIXME: Why "m_"? */ > > I don't recall why "m" in particular It probably stands for "member". This is a widely used coding convention, except that Emacs never used it -- until now. We use foo_ in other places for similar reasons, perhaps we should do that here as well, for consistency, if nothing else. Here are a few more questions/comments, based on some reading of the code. Some of the below is relevant to how the infrastructure in systhread.c might be ported to Windows. In no particular order: . The compute_*_wait_mask functions in process.c could use some more meaningful names, to more clearly indicate their semantics from the caller's POV. Right now, the names simply state which bits are tested in the fd's flags (and even that is not 100% accurate, since e.g. the FOR_READ flag is not mentioned). That is hard on mnemonic memory, especially since some of the functions define their purpose in negative form (compute_NON_keyboard_wait_mask). . Why is systhread.c on a separate file? Wouldn't it be better to have this code in thread.c instead? It's not like thread.c can be compiled in without also compiling systhread.c, right? . Will the handling of SIGCHLD be thread-specific or global? IOW, if a thread fires up a subprocess, which exits while another thread is running, which thread(s) will get the signal? If the signal arrives at some other thread, how will that thread know to handle it, if it doesn't watch the corresponding fd's? . I'm not sure I understand the rationale for the synchronization primitives that were implemented. AFAIU, we have mutexes, and we have condition variables, and their basic functionalities are exposed all the way to the Lisp level. But mutexes are implemented as condition variables under the hood. Why is that? is that only to be able to interrupt a wait for mutex without relinquishing the mutex? If the latter, then what is the real difference between these two, since both condition variable is also released by signaling it? (Btw, the lispref manual mentions 'condition-signal', does it mean 'thread-signal' instead? there's no mention of 'condition-signal' anywhere else, AFAICS.) . The issue with signals to thread is unclear to me. threads.texi says: @defun thread-signal thread error-symbol data Like @code{signal} (@pxref{Signaling Errors}), but the signal is delivered in the thread @var{thread}. If @var{thread} is the current thread, then this just calls @code{signal} immediately. @code{thread-signal} will cause a thread to exit a call to @code{mutex-lock}, @code{condition-wait}, or @code{thread-join}. @end defun A call to 'signal' throws to a handler or to top level, but what does the latter mean in a thread, where (AFAIU) there's no top level? will the thread be forced to exit (there's a hint that "a thread cannot be exited, but [...] other threads can be signaled")? if not, what will happen to it, after it exits the blocking wait calls? And how is this thread signaling a generalization of the current single-threaded 'signal'? . threads.texi mentions the "current thread", but never explains what that is. For Lisp code, that's probably the thread which runs the code, but what, if anything, does "current thread" mean on the C level? Since several threads could potentially be running at the same time, is there any meaning to talk about "current thread" except in the context of some Lisp code? And what about the main thread, btw, the one created when Emacs starts? Is that thread "more equal than others", or is it just like the others? . If a thread dies (because the underlying thread implementation hits some fatal error) while it holds a mutex, will the mutex be released? . Finally, if condition variables are unavailable (they are a pain on Windows, since only the latest versions support them natively), is it still possible to have threads, just without some synchronization features? Or are condition variables currently a must for the threading mechanism itself? Well, that's enough for now. Thanks in advance for reading and commenting.