Re: SCM_SYSCALL

[Mark H Weaver]

Hi Ludovic,

address@hidden (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