Re: work-around for EINTR error

i've seen somewhere that there is a way to have auto-restart for most of the
calls, I think I saw that in signal help
in devhelp in Debian, the chapter is called 'Signal handling'

there is a sigaction(..., SA_RESTART, ...) (with the ... being the right
stuff for you)
there is also a wrapper TEMP_FAILURE_RETRY but the sigaction stuff would be
probably more practical

WIH
Armel

<pvl_google@xxxxxxxxx> a écrit dans le message de news:
1147867032.314943.136180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi,

We're porting a multithreaded application to Linux using the NPTL
pthreads library, and using gdb/eclipse for debugging. When gdb wants
to stop the application (breakpoints and single stepping), it sends a
SIGSTOP to all threads within the process.

Reading the manpages, I found that a lot of system + std libary calls
may be interrupted by this (and other) signals and return with EINTR.
Apparently it's up to the user to explicitly "restart" such calls,
taking into account extra difficulties for some:
- sleeps must be restarted with remaining time
- writes must be restarted with the remaining number of bytes
- (f)printf can be interrupted in the midst of printing output
- (f)scanf can be interrupted while reading input

I find it at least cumbersome to implement such behaviour at
application level (is there any reason why one would not want to
restart the call ?). And it's also a risk, because there are really a
lot of calls which may be interrupted and it's easy to overlook one,
possibly yielding sporadic erroneous behavior.

Now I wonder whether there is a standard work-around for this problem,
like:
- some setting or hack to avoid call interruption
- a glibc version/patch that automatically restart calls
- a reference "wrapper" doing the restart
- any other...


Thanks,
Pieter



.

Relevant Pages

  • work-around for EINTR error
    ... Apparently it's up to the user to explicitly "restart" such calls, ... scanf can be interrupted while reading input ... possibly yielding sporadic erroneous behavior. ... some setting or hack to avoid call interruption ...
    (comp.os.linux.development.apps)
  • Re: [PATCH -v2] fix for futex_wait signal stack corruption
    ... but these other signals did not cause the immediate return. ... things correctly, any interruption of pthread_cond_timedwait by a signal, ... And I think two threads racing to pick up the same signal can cause it too, for that matter (ie one thread takes the signal, the other one got interrupted but there's nothing there, so it just causes a system call restart). ...
    (Linux-Kernel)
  • Re: [PATCH -v2] fix for futex_wait signal stack corruption
    ... other signals might cause pthread_cond_timedwait to return immediately in the ... things correctly, any interruption of pthread_cond_timedwait by a signal, ... There's basically two different system call restart mechanisms in the ... system call gets interrupted by a signal, but no signal handler actually ...
    (Linux-Kernel)
  • Re: RFC: Kill -ERESTART_RESTARTBLOCK.
    ... For pselect(), lots of them. ... > change the restart logic. ... Delivering signals by calling do_signalisn't really that messy -- no ...
    (Linux-Kernel)
  • Re: [PATCH] PPC32: cancel syscall restart on signal delivery
    ... > system call instruction itself actually did the restart ... > handler) to the same program. ... as though you have interrupts disabled all the way from before you ... return to userspace even if there are more signals pending. ...
    (Linux-Kernel)