This also includes SIGALRM. Thus just ignoring EINTR and continuing would break timeout handling using an ALARM handler.
In theory yes, but in practice it is not usually done that way, instead, the common approach is to call die from the signal handler.
But in my opinion there is an explicit SIGCHLD handler in the code not shown so the application explicitly asks for signals and therefore has to properly deal with these
So, when writing code using IO::Socket::SSL you have to take into account how other parts of your program, maybe unrelated, work? In the end, what you are saying is that for anything but small scripts the module user has to handle EINTR errors explicitly always.
IMO, this puts unnecessary burden on the module user just for the rare case when he would need to handle EINTR himself. That goes against the Perl principle saying that "Easy things should be easy, and hard things should be possible". So my conclusion is that at least the new method should take care of handling EINTR itself, in the same way it already does for readline for instance. For the case where the user wants to handle EINTR himself, he can revert to using lower level methods.
In reply to Re^7: IO::Socket::SSL sometimes says 'SSL wants a read first'
by salva
in thread IO::Socket::SSL sometimes says 'SSL wants a read first'
by FloydATC
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |