Re: Re: Strange Linux behaviour with blocking syscalls and stop signals+SIGCONT

[angelo.borsotti@gmail.com]

I would venture to suggest a possible solution. But let's fist see what
could be a reasoneable goal to achieve. Compatibility with existing
applications is a must, so, solutions must not break it.
Easy porting applications written for other Unixes is also a desirable
feature. Being able to write correct programs that cope with stopping/
continuing is also a must.
The very last (correctness) cannot be achieved with the existing API:
suppose you are implementing a library, and you want to cope with
stopping (i.e. make the process using the library continue properly
after having been stopped). You cannot simply restart calls (the 16
ones that are interrupted by stop signals) because EINTR can be
returned also when other signals have been catched. You cannot either
rely on some flags set in a handler for SIGCONT because handlers
might be already in place when your library functions are called
(and you cannot change them since they are out of your control).
A possible solution to consider is to have the kernel store the number
of the signal that interrupted a call so that user code can decide
the action that is most appropriate for the signal received.
Since this adds to the existing API, it cannot break existing programs.
People that want to port code from other Unixes can do that simply
writing wrappers for the 16 syscalls that restart them when a stop
signal is received. People that want to cope with stop signals in new
code can restart them testing the signal that interrupted the calls
(it would use a feature that is not in the POSIX standard, but it
would work).

--
This message was sent on behalf of angelo.borsotti@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/4393984.html