One more point, and then I'll try to shut up. ;)
You could argue that we could just fix this and deprecate "fake
non-blocking I/O" for future major versions. The argument would be that this
won't break any application that's not broken already and might fix existing
applications.
My response to that would be that there might be applications that
erroneously call SSL_read expecting it to block until application data is
available because it has before in their testing. They can argue that they
set the socket blocking specifically so that it would block. (It seems the
cases in which SSL_read blocks after a read select hit are consistent given
consistent timing, so code could rely on it.)
Is their code broken already? I suppose, because they wanted retries and
didn't ask for them. But your code wanted non-blocking and didn't ask for
it.
I would argue that a change that can only fix definitely broken code and
can break only probably broken code isn't worth making. There's an obvious
way to get total fixing in a subsequent version, match the semantics of
'read' in 'SSL_read'.
One other point, I didn't mention threads to argue that if another
thread
steals your data, the operation will clearly block. I mentioned it to show
that it's impossible for 'select' to guarantee even that the next operation
will block without breaking valid code. (Because that would require kernel
omniscience to divine the intent of the programmer.)
Consider:
1) Thread A get a write hit from 'select' for blocking socket 9.
2) Thread B does a 129,029 byte 'write' to socket 9. (It may or may not be
relying on the write hit from 'select', the implementation cannot tell.)
Should that write block or not? If you really think 'select' could ever
guarantee that a future operation will not block, then the kernel should
remember the 'select' hit and return immediately from that 'write'. However,
the implementation has no way to know that the call to write from thread B
had anything to do with the call to 'select' from thread A. Perhaps the code
is unrelated and thread B needs normal blocking behavior. (Think of the
bizarre race conditions this would cause.)
I understand the semantic difference between read and write, that's not
my
point here. My point is that 'select' can't control what a subsequent
operation does because there's no way to positively identify a particular
operation as 'subsequent' and the behavior you are expecting can break code
that doesn't specifically ask for it. (Though I would argue that not
checking for short reads on a blocking socket is a bug too, it's also
common. But that's a whole other pet peeve of mine.)
If you still believe that 'select' makes a subsequent 'read' on a socket
non-blocking even if the socket is set blocking, just tell me one thing --
how do I ask for a *blocking* 'read' after a 'select' if that's what I want?
(And there are certainly protocols where blocking reads could mean
something, consider MSG_WAITALL.) Should I set the already-blocking socket
blocking again?
There's an obvious common-sense way to resolve this, and pretty much
only
one way -- if the application wants non-blocking behavior, it has to ask for
it. If it asks for blocking behavior, it should get that.
Okay, I'll shut up now. This is just one of my pet peeves because it's a
bug I have to frequently track down and fix and I'm getting tired of people
evangelizing *for* the bug and encouraging people to make it.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
