unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Chris Vine <chris@cvine.freeserve.co.uk>
To: 18988@debbugs.gnu.org
Subject: bug#18988: select failure with EINTR in guile-2.0.11
Date: Mon, 17 Nov 2014 18:11:06 +0000	[thread overview]
Message-ID: <20141117181106.7deb8e59@bother.homenet> (raw)
In-Reply-To: <20141107171809.5ff33de4@bother.homenet>

On looking at the code in filesys.c, it is evident that EINTR is not
handled by select as described in the documentation, and that there are
three solutions to this:

1.  To do what the documentation says, and to handle EINTR by returning
rather than by throwing a system-error exception ("[select] also returns
if interrupted by a signal").  Pros: it probably matches what people
have been coding to since that is what is currently (but wrongly)
documented as happening; and it still provides an opportunity for a
program relying on a timeout to decide what to do if the system call
returns prematurely.  Cons:  It is very difficult for user code to
restart the call with an appropriately reduced new timeout period
representing the residue of the timeout period - but that is something
users of select must expect anyway because a file descriptor becoming
ready will have the same effect (and there is always the SA_RESTART
flag).

2.  To restart with an appropriately reduced timeout representing the
residue of the timeout period.  Pros: EINTR is handled seamlessly as
if by SA_RESTART.  Cons:  Although linux modifies the timeout argument
on returning to indicate the unexpired period of a timeout, I believe
the BSDs do not (I have no idea what windows does). For OSs that do not
provide this information, there are two sub-choices - behave as in 1
above, or to just restart and accept that the timeout might be much
delayed in the presence of interrupts by wrapping the select call with
SCM_SYSCALL (in theory, on a long timeout with many interrupts, the
timeout may never occur at all).

3.  To correct the documentation but leave select throwing an exception
on an interrupt occuring, by saying in the documentation that rather
than select returning, it throws a system-error exception with errno
set to EINTR.

On balance I would go for 1 above.  I am happy to submit a patch, but
won't do so unless I know that that is the behaviour that is wanted.





  reply	other threads:[~2014-11-17 18:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 17:18 bug#18988: select failure with EINTR in guile-2.0.11 Chris Vine
2014-11-17 18:11 ` Chris Vine [this message]
2014-11-20 20:34   ` Ludovic Courtès

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=20141117181106.7deb8e59@bother.homenet \
    --to=chris@cvine.freeserve.co.uk \
    --cc=18988@debbugs.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).