in reply to Re^4: IO::Socket::SSL sometimes says 'SSL wants a read first'
in thread IO::Socket::SSL sometimes says 'SSL wants a read first'

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.

Replies are listed 'Best First'.
Re^6: IO::Socket::SSL sometimes says 'SSL wants a read first'
by noxxi (Pilgrim) on Apr 21, 2017 at 05:03 UTC
    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]
      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.

[reply]
[d/l]
[select]

        You have some point that easy things should be easy. But, different users have a different understanding of what is easy and how they expect programs to behave. IO::Socket::SSL is not specifically designed to make it harder. Regarding EINTR it just behaves like all the other IO::Socket modules and it would in my opinion against the expectations if it would behave differently. Just try the following code and you'll see that IO::Socket::INET behaves the same regarding EINTR, i.e. breaks the connect if SIGCHLD is triggered before the connect is done:

        $SIG{CHLD} = sub { warn "child returned" };
if (!fork()) {
    sleep(1);
    exit(0);
}
# parent: fails with EINTR if child returns before connect succeeds
my $cl = IO::Socket::INET->new('some_host:dropped_port') or die $!;

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom