unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* a little puzzle
@ 2010-10-08 17:14 Andy Wingo
  2010-10-08 17:32 ` Andy Wingo
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Wingo @ 2010-10-08 17:14 UTC (permalink / raw)
  To: guile-devel

Put this in your REPL and smoke it:

    (define* (make-me-a-socket #:key
                               (host #f)
                               (addr (if host (inet-aton host) INADDR_LOOPBACK))
                               (port 37146))
      (let ((server (socket PF_INET SOCK_STREAM 0)))
        (setsockopt server SOL_SOCKET SO_REUSEADDR 1)
        (bind server AF_INET addr port)
        (listen server 5)
        server))

    (sigaction SIGINT (lambda (sig) (throw 'foo)))

    (define s (make-me-a-socket))
    (accept s) ; Now Ctrl-C

What do you expect to happen here?

Probably not this:

    ERROR: In procedure accept:
    ERROR: Interrupted system call
    Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
    scheme@(guile-user) [1]> 
    Throw to key `foo' with args `()' while reading expression.
    scheme@(guile-user) [1]> 

That's right: two throws for the price of one! The interrupted syscall,
and then the asynchronous signal. Fun...

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: a little puzzle
  2010-10-08 17:14 a little puzzle Andy Wingo
@ 2010-10-08 17:32 ` Andy Wingo
  2010-10-10 14:58   ` Andy Wingo
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Wingo @ 2010-10-08 17:32 UTC (permalink / raw)
  To: guile-devel

On Fri 08 Oct 2010 19:14, Andy Wingo <wingo@pobox.com> writes:

>     ERROR: In procedure accept:
>     ERROR: Interrupted system call
>     Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>     scheme@(guile-user) [1]> 
>     Throw to key `foo' with args `()' while reading expression.
>     scheme@(guile-user) [1]> 
>
> That's right: two throws for the price of one! The interrupted syscall,
> and then the asynchronous signal. Fun...

I propose to fix it with a patch like this:

--- a/libguile/error.c
+++ b/libguile/error.c
@@ -147,6 +147,7 @@ void
 scm_syserror (const char *subr)
 {
   SCM err = scm_from_int (SCM_I_ERRNO ());
+  SCM_ASYNC_TICK;
   scm_error (scm_system_error_key,
 	     subr,
 	     "~A",
@@ -157,6 +158,7 @@ scm_syserror (const char *subr)
 void
 scm_syserror_msg (const char *subr, const char *message, SCM args, int eno)
 {
+  SCM_ASYNC_TICK;
   scm_error (scm_system_error_key,
 	     subr,
 	     message,

I am not clear that it's guaranteed that the thread will be ready for an
async though. This seems to work but it does not seem reliable.

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: a little puzzle
  2010-10-08 17:32 ` Andy Wingo
@ 2010-10-10 14:58   ` Andy Wingo
  0 siblings, 0 replies; 3+ messages in thread
From: Andy Wingo @ 2010-10-10 14:58 UTC (permalink / raw)
  To: guile-devel

On Fri 08 Oct 2010 19:32, Andy Wingo <wingo@pobox.com> writes:

> On Fri 08 Oct 2010 19:14, Andy Wingo <wingo@pobox.com> writes:
>
>> That's right: two throws for the price of one! The interrupted syscall,
>> and then the asynchronous signal. Fun...
>
> I propose to fix it with a patch like this:
>
> --- a/libguile/error.c
> +++ b/libguile/error.c
> @@ -147,6 +147,7 @@ void
>  scm_syserror (const char *subr)
>  {
>    SCM err = scm_from_int (SCM_I_ERRNO ());
> +  SCM_ASYNC_TICK;
>    scm_error (scm_system_error_key,
>  	     subr,
>  	     "~A",

I did so, wrapping in #ifdef EINTR, and with the additional comment:

  /* It could be that we're getting here because the syscall was
     interrupted by a signal.  In that case a signal handler might have
     been queued to run.  The signal handler probably throws an
     exception.

     If we don't try to run the signal handler now, it will run later,
     which would result in two exceptions being thrown: this syserror,
     and then at some later time the exception thrown by the async
     signal handler.

     The problem is that we don't know if handling the signal caused an
     async to be queued.  By this time scmsigs.c:take_signal will have
     written a byte on the fd, but we don't know if the signal-handling
     thread has read it off and queued an async.

     Ideally we need some API like scm_i_ensure_signals_delivered() to
     catch up signal delivery.  Barring that, we just cross our digits
     and pray; it could be that we handle the signal in time, and just
     throw once, or it could be that we miss the deadline and throw
     twice.
  */
#ifdef EINTR
  if (scm_to_int (err) == EINTR)
    SCM_ASYNC_TICK;
#endif

-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-10-10 14:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-08 17:14 a little puzzle Andy Wingo
2010-10-08 17:32 ` Andy Wingo
2010-10-10 14:58   ` Andy Wingo

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).