From: Mark H Weaver <mhw@netris.org>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: SCM_SYSCALL
Date: Wed, 03 Jul 2013 14:19:24 -0400 [thread overview]
Message-ID: <878v1nfqvn.fsf@tines.lan> (raw)
In-Reply-To: <87li607c5l.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Jun 2013 23:25:10 +0200")
Hi Ludovic,
ludo@gnu.org (Ludovic Courtès) writes:
> We have this (since 2010):
>
> # define SCM_SYSCALL(line) \
> do \
> { \
> errno = 0; \
> line; \
> if (errno == EINTR) \
> { \
> SCM_ASYNC_TICK; \
> continue; \
> } \
> } \
> while(0)
>
> It turns out that the effect upon EINTR is to leave the loop. So
> typically, fport_fill_input just throws to system-error and reveals the
> EINTR, contrary to SCM_SYSCALL intends to do.
Ugh. Well, I guess this finally explains <http://bugs.gnu.org/13018>.
Thanks for tracking this down.
> This is easily fixed, but the question is whether this would affect
> users in bad ways. For example, applications might be relying on the
> ability to do
>
> (catch 'system-error
> ...
> (lambda args
> (if (= EINTR (system-error-errno args))
> ...)))
>
> Should the fix be delayed until 2.2?
> WDYT?
I strongly believe that we should fix this in stable-2.0. While it is
true that the above scenario is possible, I suspect it is at least an
order of magnitude more common for Guile-based software to be written
based on the presumption that EINTR is handled automatically.
Not only did all versions of Guile 1.x automatically handle EINTR, but
most of us assumed that this behavior was unchanged in Guile 2.0 and
wrote our software based on that assumption. I certainly did.
As it is now, even portable Scheme code that uses (read) might result in
exceptions being thrown semi-randomly. We cannot reasonably expect
Guile programs to put each (read) within a loop to handle EINTR.
Please, let's fix this in stable-2.0.
What do you think?
Mark
next prev parent reply other threads:[~2013-07-03 18:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-23 21:25 SCM_SYSCALL Ludovic Courtès
2013-07-03 18:19 ` Mark H Weaver [this message]
2013-07-04 22:28 ` SCM_SYSCALL Ludovic Courtès
2013-07-05 18:56 ` SCM_SYSCALL Mark H Weaver
2013-07-05 20:01 ` SCM_SYSCALL Ludovic Courtès
2013-07-06 16:41 ` SCM_SYSCALL Mark H Weaver
2013-07-06 21:05 ` SCM_SYSCALL Ludovic Courtès
2013-07-17 16:04 ` SCM_SYSCALL Ludovic Courtès
2014-03-23 19:56 ` SCM_SYSCALL Andy Wingo
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=878v1nfqvn.fsf@tines.lan \
--to=mhw@netris.org \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.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).