On 10/9/2017 7:49 AM, Jakob Bohm wrote:
On 09/10/2017 16:43, Thomas J. Hruska wrote:
On 10/9/2017 7:29 AM, Jakob Bohm wrote:
I suggest you find a good authoritative source for your claim
that select() should not be used with blocking sockets.
http://man7.org/linux/man-pages/man2/select.2.html
Section BUGS:
"Under Linux, select() may report a socket file descriptor as "ready
for reading", while nevertheless a subsequent read blocks. This could
for example happen when data has arrived but upon examination has
wrong checksum and is discarded. There may be other circumstances in
which a file descriptor is spuriously reported as ready. Thus it may
be safer to use O_NONBLOCK on sockets that should not block."
Authoritative enough for you?
That must be a recent change then. But certainly that is a bug
in Linux select, not in programs relying on the (long time)
documented correct behavior.
The OpenSSL layer over TCP/IP complicates matters more across ALL
platforms: SSL_read() may need to write (and SSL_write() may need to
read). Even if the socket has data to read according to select(), if
the respective write end is full (or vice versa for SSL_write()), then
the call WILL block when using blocking sockets.
You can't resolve the above issue with select() or any other function
UNLESS you switch to non-blocking socket descriptors. From that point,
the only logical conclusion that can be drawn is that select() is for
non-blocking I/O only. Then the documented "bug" in Linux becomes a
misunderstanding of what select() is actually intended for across all
platforms: Preventing spurious CPU usage for non-blocking I/O.
select() is just a notification that MAYBE you can read or MAYBE you can
write, but there is no guarantee of either succeeding.
--
Thomas Hruska
Shining Light Productions
Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
