From: "Михаил Бахтерев" <mob@k.imm.uran.ru>
To: Mark H Weaver <mhw@netris.org>
Cc: 32786@debbugs.gnu.org
Subject: bug#32786: (system* ...) call somehow interferes with atomic-box on armv7l
Date: Sat, 22 Sep 2018 09:39:38 +0500 [thread overview]
Message-ID: <20180922043938.GA4539@blacky> (raw)
In-Reply-To: <87fty2v8xo.fsf@netris.org>
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
next prev parent reply other threads:[~2018-09-22 4:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 17:13 bug#32786: (system* ...) call somehow interferes with atomic-box on armv7l Михаил Бахтерев
2018-09-21 21:26 ` Mark H Weaver
2018-09-22 4:39 ` Михаил Бахтерев [this message]
2018-09-22 4:50 ` Михаил Бахтерев
2018-09-27 5:49 ` Mark H Weaver
2018-09-27 6:18 ` Михаил Бахтерев
2018-10-05 19:43 ` Михаил Бахтерев
2018-10-05 23:22 ` Mark H Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180922043938.GA4539@blacky \
--to=mob@k.imm.uran.ru \
--cc=32786@debbugs.gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).