I'm not sure what you expect as the correct behavior for EINTR. In my experience the correct behavior is that the program has to explicitly deal with this case, typically by restarting the operation. This is the case for both non-SSL and SSL sockets. | [reply] |
How do you restart new?
What does the module user get for being able to handle EINTR errors himself that justifies not hidden those events inside the library?
IMO, leaving EINTR handling to the user just makes writing reliable software with this module much harder. I am sure almost no code using IO::Socket::SSL out there actually handles EINTR correctly, and for those few cases, probably none does anything besides just retrying the last operation.
| [reply]
[d/l]
[select] |
EINTR happens when a signal gets delivered. This also includes SIGALRM. Thus just ignoring EINTR and continuing would break timeout handling using an ALARM handler. A simple application does not deal with signals and it will not get signals and thus no special handling of EINTR needs to be done. 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. While IO::Socket::SSL->new cannot be restarted the proper way is to just create the SSL socket without handshake as documented and then explicitly do the handshake with connect_SSL or accept_SSL. These operations can be restarted. BTW, this is true for IO::Socket::INET too.
| [reply] |