From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?=D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB_?= =?UTF-8?Q?=D0=91=D0=B0=D1=85=D1=82=D0=B5=D1=80=D0=B5=D0=B2?= Newsgroups: gmane.lisp.guile.bugs Subject: bug#32786: (system* ...) call somehow interferes with atomic-box on armv7l Date: Sat, 22 Sep 2018 09:39:38 +0500 Message-ID: <20180922043938.GA4539@blacky> References: <20180920171306.GA9185@k> <87fty2v8xo.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1537592649 12780 195.159.176.226 (22 Sep 2018 05:04:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Sep 2018 05:04:09 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 32786@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat Sep 22 07:04:05 2018 Return-path: Envelope-to: guile-bugs@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 1g3a5L-0003CO-AP for guile-bugs@m.gmane.org; Sat, 22 Sep 2018 07:04:05 +0200 Original-Received: from localhost ([::1]:58379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g3a7R-0005h3-Le for guile-bugs@m.gmane.org; Sat, 22 Sep 2018 01:06:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g3a7J-0005gt-Rt for bug-guile@gnu.org; Sat, 22 Sep 2018 01:06:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g3a7G-0003vX-G6 for bug-guile@gnu.org; Sat, 22 Sep 2018 01:06:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44384) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g3a7G-0003vM-1t for bug-guile@gnu.org; Sat, 22 Sep 2018 01:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g3a7F-0001L0-PR for bug-guile@gnu.org; Sat, 22 Sep 2018 01:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB_?= =?UTF-8?Q?=D0=91=D0=B0=D1=85=D1=82=D0=B5=D1=80=D0=B5=D0=B2?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 22 Sep 2018 05:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32786 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 32786-submit@debbugs.gnu.org id=B32786.15375927405099 (code B ref 32786); Sat, 22 Sep 2018 05:06:01 +0000 Original-Received: (at 32786) by debbugs.gnu.org; 22 Sep 2018 05:05:40 +0000 Original-Received: from localhost ([127.0.0.1]:48640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g3a6t-0001K9-Gw for submit@debbugs.gnu.org; Sat, 22 Sep 2018 01:05:39 -0400 Original-Received: from k.imm.uran.ru ([195.19.132.74]:38334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g3Zhm-0000dp-Qg for 32786@debbugs.gnu.org; Sat, 22 Sep 2018 00:39:43 -0400 Original-Received: from blacky (88.226-224-87.telenet.ru [87.224.226.88]) by k.imm.uran.ru (Postfix) with ESMTPSA id B50BB19352; Sat, 22 Sep 2018 09:39:39 +0500 (+05) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=k.imm.uran.ru; s=kite; t=1537591179; bh=0n2Md/lMgViMYoTlX9BP9m+CTeKMOclhw3iM/k8VAO0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IfAgMSynYBICy7kQYeAKNSzyaJqYbxU/s5oSAyiiwKOccrGDfR88GiJ4MJbOW7NXA Z/9V0iwwRs3wJVQkuoF7OlnQgFvbKQ2wa5piYHaOZDkpPvAQasGacsMfqn5g6vseu4 1e0bcb5YOZT6th/znWnTbe5y50686UndVt5lCl2nn6F/L/Jyv6k9tywmpGbi+ndEUX MBNVKxVmTutY4gVK7cPoAjXXaS+Nf/clLyxoFVVF/Nqc3xygSt3L5mI83apTvKOXsB VcX0TPYYS7Fap5HDMsle53NuWgXM5dJW2D/3TbUBZwqCXPk3s918FJ5LvOJgmtQrpY nYvJ8gBzckxrty7wWDLg0Lafdik+lPGJlIViNhmEIzWfFHfDaKvrfQCt7f/KcMsqjD c7IeNDOUCGRSNWeh5yrlwf0x/r2h3w+XuhmjFW1zpNGqpyc570O3mvz2PIFJwBwHfm Fjm1gGGPhyAcijTa7ghtxRhoaK2YVwPvuzslDTR2N38huyWOWcSiS5dzXyc8WZMKsD MVrTEkQEZgdad/PzOu+4IcdKI/8rV4dphN55vN5uqHW/PSrbaAyl/Jd4m9xn4BNjqV 7odqT5xAIrdMi9nusvtMyEomJnMSJjYB+Q1yVN8U0ZVImmydI5e/WMdvwraEYWSbSS eqmoi+u/woVuCW3Ub3vsPyzM= Content-Disposition: inline In-Reply-To: <87fty2v8xo.fsf@netris.org> X-Mailman-Approved-At: Sat, 22 Sep 2018 01:05:38 -0400 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-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:9165 Archived-At: On Fri, Sep 21, 2018 at 05:26:27PM -0400, Mark H Weaver wrote: > Hi, > > Can you describe in more detail the behavior you are seeing? What > messages do you see on stderr from your 'dump' calls when it gets stuck? > What state is the atomic box left in? > > I see a couple of problems with the code below: > > * Two threads write concurrently to the same port, namely > (current-error-port). You should use thread synchronization to ensure > that operations to a given port are serialized. > > * There's a race condition when the atomic box is in the #:accepted > state. If the main thread finds the box in that state, it changes the > state to #:need-to-sleep, which will apparently cause the other thread > to sleep again. > > I'm not sure if these problems could explain what you're seeing. > > Regards, > Mark > The code is supposed to model the following behaviour. The main thread tracks some events (in the example: the end of (sleep 3)). If one or multiple events occurred some long-lasting external command should be executed. Long-lasting means that multiple events may occur during execution. To perform that the main thread should: 1. either to run new work thread (sleep-loop procedure), which will call (system* ...); 2. or to communicate the fact of events occurrences to the work thread, which is supposed to detect this and just repeat the command. If multiple events have occurred during command execution the command should be re-executed only once. The event occurrence is communicated through simple protocol with three states: #:nothing-to-do < #:accepted < #:need-to-sleep. The main thread pulls state up, and work thread pulls it down. When the main thread detects event, and the state is #:accepted, it means, that work thread accepted the previous job, and executing it now, so the main thread pulls the state up to need-to-sleep, and the work thread re-executes command (sleeps again in the test case), when the previous external command run has finished. This is intended behaviour. I expect the program to print some garbage, showing that work thread is restarted periodically. Something like that (it is result of using (sleep 1) instead of (system* "sleep" "1s")): $ guile test.scm M: (sleep 3) M: protocol exchange M: new sleep thread M: (sleep 3) R: Going to (sleep 1) R: sleep-loop finished M: protocol exchange M: new sleep thread M: (sleep 3) : (sleep 3)R: Going to (sleep 1) R: sleep-loop finished M: protocol exchange M: new sleep thread M: (sleep 3) R: Going to (sleep 1) R: sleep-loop finished M: protocol exchange M: new sleep thread M: (sleep 3) : (sleep 3)R: Going to (sleep 1) R: sleep-loop finished But what i get with (system* "sleep" "1s") is this: $ guile test.scm M: (sleep 3) M: protocol exchange M: new sleep thread M: (sleep 3) R: Going to (sleep 1) R: sleep-loop finished M: protocol exchange M: (sleep 3) M: protocol exchange M: (sleep 3) M: protocol exchange M: (sleep 3) So, the state of the atomic-box is stuck in #:need-to-sleep somehow. - MB. Respectfully