From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.devel Subject: Re: semantics of thread-signal Date: Sun, 11 Dec 2016 21:06:38 -0500 Message-ID: References: <871sxe2b8d.fsf@irif.fr> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1481508469 18214 195.159.176.226 (12 Dec 2016 02:07:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2016 02:07:49 +0000 (UTC) Cc: Emacs developers To: Juliusz Chroboczek Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 12 03:07:46 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 1cGG1o-0003uO-Jy for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2016 03:07:44 +0100 Original-Received: from localhost ([::1]:57990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGG1s-000222-Gb for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 21:07:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGG1m-00021w-Ma for emacs-devel@gnu.org; Sun, 11 Dec 2016 21:07:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cGG1j-0006WS-HH for emacs-devel@gnu.org; Sun, 11 Dec 2016 21:07:42 -0500 Original-Received: from mail-oi0-f44.google.com ([209.85.218.44]:34288) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cGG1j-0006WO-CK for emacs-devel@gnu.org; Sun, 11 Dec 2016 21:07:39 -0500 Original-Received: by mail-oi0-f44.google.com with SMTP id y198so74590875oia.1 for ; Sun, 11 Dec 2016 18:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ya0FHYnFZVRokhen05hGi4edhTadyqAIsBlPSIgHuBk=; b=WEsXOvlSI5GYqNbwMa09XVKmW0QfH3a6cEkTOo7QKtETEcd2vRoo5Dp+yzNywxdXmA 867Fv8okI7X4Wvba38HJrj3xdt2uELZtMs7nAL18GVU60dD0dwTm5QXDatrURUxyo61R dm3N54cblVeRUPuKzklTVsPGifQUn84gNN9OzGWtFdaJkx+V0jyDCq99ryvx0kmfXdAt zV94PWzzgRbb1UJrvqtipgFWeA5vPucpf3kvfmObhKBhZJZhwly7QghTRvJHZ/GQte/9 WzkPTUltbEBgZ80OCLjh60piGoF39pWRn2m+7WHBAhqVf9Nc81AG016ktJZLVwxGi1b3 lY9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ya0FHYnFZVRokhen05hGi4edhTadyqAIsBlPSIgHuBk=; b=JcqdzkYoTjKGNduIaHnssdSQdyCoUgdRq6Me4CLjmhc8s5lpSwrqbipkoHpv1DmnIU zXIFV6bVXw1/aY6Ld+qo6CJ/vO3zUXiGMvpKd9sO4gL7dL+01ERndWdaS8Ns8F34bj5F Yu8aBGRNWn2WCbqQisiifnVWKf9O+Bf//0wpJ7DmLvV3TqxwQLMrlh5Fo3NJH/2HpFua 3aYGoy1/zjkwTRtHBkkocvAIQmMx9F8SAHaIoRYuvc3fx/3FZogdIch71R6ZX3dZlCX9 Vl4oz7XXCg9+3KpNRlu5caPmQKeH9lZYCFidogFY9YhWR/4O6VIt18B6XtDd5Vzxyrf9 132w== X-Gm-Message-State: AKaTC03cmqE/nRYZTY7BT87tzdCyjsrl/1EP8DKvm+3+jiBSLxiHgHHPto6LeN0cCrJw7wFMeZmCeeV57NzrSg== X-Received: by 10.157.58.119 with SMTP id j110mr47784239otc.208.1481508398379; Sun, 11 Dec 2016 18:06:38 -0800 (PST) Original-Received: by 10.157.6.234 with HTTP; Sun, 11 Dec 2016 18:06:38 -0800 (PST) In-Reply-To: <871sxe2b8d.fsf@irif.fr> X-Google-Sender-Auth: -0UVfeKOEquDxdHKLwqIDIMigeA X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.218.44 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:210320 Archived-At: On Sun, Dec 11, 2016 at 8:21 PM, Juliusz Chroboczek wrote: >>> I assumed this to mean that the condition will only be delivered when >>> one of these functions is called, but your comment seems to imply that >>> it's meant to deliver the condition as soon as possible. > >> My interpretation is that mutex-lock (and the others) block the thread >> until something happens (e.g., another thread calls mutex-unlock), and >> thread-signal is another thing which can end the blocking (and also >> trigger a signal when the thread next runs). > > Reasonable enough. Perhaps somebody could clarify the docs? > Something like this? --- i/doc/lispref/threads.texi +++ w/doc/lispref/threads.texi @@ -82,9 +82,11 @@ Basic Thread Functions @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}. +thread, then this just calls @code{signal} immediately. Otherwise, +@var{thread} will receive the signal as soon as it becomes current. +If @var{thread} was blocked by a call to @code{mutex-lock}, +@code{condition-wait}, or @code{thread-join}; @code{thread-signa} will +unblock it. @end defun > > The manual says: > > However, the Emacs thread support has been designed in a way to > later allow more fine-grained concurrency, and correct programs > should not rely on cooperative threading. > > So if thread-signal can be delivered asynchronously, this will cause > trouble when Emacs moves to kernel threads. Hmm, if we really want to be safe for preemptive threads, we would probably need to add some way to block asynch signals, and unwind-protect would use that during the unwind forms. It would also be needed between calling make-foo and setting the value of foo.