If you are using non-blocking sockets you usually have some kind of event loop, i.e. read on the socket only if your event loop triggered the event that the socket is readable. Such an event loop is done by $sel->can_read in case you are using IO::Select. But if you use other event loops like for example kqueue, EV ... the exact syntax of getting the "socket readable" from the event loop differs.

The important difference between a normal socket and a SSL socket is that for a normal socket data availability is handled fully inside the OS kernel and the event loop will thus return the data available event if and only if data are available (or socket closed).

With SSL sockets instead a large part is handled in user space and due to the SSL framing of data it can happen, that a data available is shown by the OS socket based event loop even though a sysread will not result in any data. This is the case if for example 1500 bytes could be read from the socket but the SSL frame had a size of 6000 bytes, i.e. more data are needed to decrypt the SSL frame and return the data inside sysread. It could also happen, that the event loop does not signal data availability but a sysread would actually return data. This happens for example if you do a sysread of 500 bytes but the SSL frame containing these 500 bytes had actually 1000 bytes in it. In this case the 500 bytes are returned inside the sysread and the rest is kept inside the SSL object in user space. A check against the kernel socket will not show that there are still data available but a check with $ssl->pending will show that there are still data pending inside the SSL object for another sysread.