From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Wed, 19 Oct 2016 14:57:05 +0300 Message-ID: <83mvi0v9f2.fsf@gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> <874m4aic0g.fsf@tromey.com> <7D150317-7A01-464D-8352-942631A3116B@raeburn.org> <8337juxb8h.fsf@gnu.org> <31A629C9-7C3B-4B5D-A5B5-38F556C4E064@raeburn.org> <83wph6vt0f.fsf@gnu.org> <646C7DAF-F7AB-48C2-AFDF-6881D2990617@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1476878351 29622 195.159.176.226 (19 Oct 2016 11:59:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 11:59:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 19 13:59:06 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bwpWE-0005Fb-T5 for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 13:58:51 +0200 Original-Received: from localhost ([::1]:47236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwpWG-0003Jv-Sn for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2016 07:58:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwpUr-0002qV-KX for emacs-devel@gnu.org; Wed, 19 Oct 2016 07:57:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwpUn-000706-BN for emacs-devel@gnu.org; Wed, 19 Oct 2016 07:57:25 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwpUn-000702-7M; Wed, 19 Oct 2016 07:57:21 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3361 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bwpUm-000556-IY; Wed, 19 Oct 2016 07:57:20 -0400 In-reply-to: <646C7DAF-F7AB-48C2-AFDF-6881D2990617@raeburn.org> (message from Ken Raeburn on Wed, 19 Oct 2016 06:18:18 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208471 Archived-At: > From: Ken Raeburn > Date: Wed, 19 Oct 2016 06:18:18 -0400 > Cc: Emacs-Devel devel > > > This could be solved by moving parts of thread.h into lisp.h, with the > > appropriate #ifdef guards. I think Lisp objects should be in lisp.h > > anyway, even if they are optional; anything else is confusing. > > For big, specialized objects like buffers, I think the modularity can help keep things organized, but where we’ve got a structure with all the per-thread state from random parts of the program, like condition handlers and regex state, we don’t have the luxury of separating things. But even if we move most of thread.h into lisp.h, I think there may still be mutual recursion between it and the other headers. We already have that, and deal with it. > >> Stefan’s message: http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00755.html > > > > I don't see that as a critical problem, perhaps because we don't yet > > realize how serious it can be. The whole purpose of trying to merge > > the concurrency branch is to collect practical experience as to what > > should and shouldn't be in this kind of Emacs feature. So I'd tend to > > let this be, until we find out we can't, and why. > > > >>>> * interaction of SIGCHLD handling and threads? > >>> > >>> Details? > >> > >> Your message http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00738.html raised questions. If they were ever satisfactorily answered, I overlooked it when putting together my notes…. > > > > That should be easy: since a subprocess is locked to a single thread, > > by default, but if that thread exits, that lock disappears And the process gets locked to some other thread. > > > SIGCHLD should be delivered to that thread. If we don't have that > > already, we should add that, it doesn't sound hard, given the > > infrastructure we already have (deliver_thread_signal etc.). > > It’s not completely trivial. Under POSIX, we get no control over which thread receives SIGCHLD due to a subprocess exiting, except if we want certain threads to block receiving the signal completely. We can use pthread_kill to explicitly send SIGCHLD to a specific thread, if it’s not blocking the signal, but we don’t know which thread until we’ve fetched the child’s pid and looked it up in some data structure; we do that by calling waitpid() but then the kernel discards the child process’s status info, so the “correct” thread can no longer respond to the signal by making another waitpid() call to collect the status info. We’d have to save the info the first time we call waitpid(). But doing it from within the signal handler could be tricky, because in that context w e’re limited to async-signal-safe functions, and helpful routines like malloc() and pthread_mutex_lock() aren’t on the list. So you are saying this problem was never encountered before in any other program out there, and doesn't already have a solution? I find that hard to believe. > On the other hand, perhaps we can create one special thread to do all the waitpid() calls and pass info to the Lisp-running threads. Sounds like an unnecessary complication, but if that's how others solve this problem, so shall we. > >> It’s easy enough to disable stack overflow checking when enabling thread support. > > > > Or add some simple code in the stack overflow handler to check if we > > are in the main thread, and if not, punt (i.e. crash). > > > >> If only one thread is allowed into the image processing code at a time (i.e., don’t release the global lock for that code) then that’s probably fine for now, and there’s probably other state there that different threads shouldn’t be mucking around with in parallel. > > > > Redisplay runs in the main thread anyway, right? If so, there's no > > problem. > > If some random thread calls (redisplay) or (sit-for …)? I think it’ll run in whichever Lisp-running thread triggers it. But, it’ll be the one holding the lock. No, sit-for causes a thread switch. > >> The keyboard.c one is the only one I’m a bit concerned about, in part because I haven’t looked at it. > > > > What part(s) of keyboard.c, exactly? > > Anything looking at getcjmp; that means read_event_from_main_queue and read_char. Like I said, I haven’t looked very closely; if the static storage isn’t ever used across a point where the global lock could be released to allow a thread switch, it may be fine. That should already be solved, or else threads cannot receive keyboard input safely.