Quote

If you have a non-blocking socket, the expected behavior on read, write, accept or connect is to set $! to EAGAIN if the operation can not be completed immediately.

Quote

With SSL handshakes might occure at any time, even within an established connections. In this cases it is necessary to finish the handshake, before you can read or write data. This might result in situations, where you want to read but must first finish the write of a handshake or where you want to write but must first finish a read. In these cases $! is set to EGAIN like expected, and additionally $SSL_ERROR is set to either SSL_WANT_READ or SSL_WANT_WRITE. Thus if you get EAGAIN on a SSL socket you must check $SSL_ERROR for SSL_WANT_* and adapt your event mask accordingly.

Using readline on non-blocking sockets does not make much sense and I would advise against using it. And, while the behavior is not documented for other IO::Socket classes, it will try to emulate the behavior seen there, e.g. to return the received data instead of blocking, even if the line is not complete. If an unrecoverable error occurs it will return nothing, even if it already received some data.

Also, I would advise against using accept with a non-blocking SSL object, because it might block and this is not what most would expect. The reason for this is that accept on a non-blocking TCP socket (e.g. IO::Socket::IP, IO::Socket::INET..) results in a new TCP socket, which does not inherit the non-blocking behavior of the master socket. And thus the initial SSL handshake on the new socket inside IO::Socket::SSL::accept will be done in a blocking way. To work around it you should better do an TCP accept and later upgrade the TCP socket in a non-blocking way with start_SSL and accept_SSL.