> If we are talking about standards, maybe you should read new releases
> of documents which you are citing as an authority. From 1997 to 2004
> many things changed:
> http://www.opengroup.org/onlinepubs/009695399/functions/select.html
Nothing that bears on this issue.
> For short:
>
> A descriptor shall be considered ready for reading when a call to an
> input function with O_NONBLOCK clear would not block, whether or not
> the function would transfer data successfully.
> (The function might return data, an end-of-file indication,
> or an error other than one indicating that it is blocked,
> and in each of these cases the descriptor shall be considered
> ready for reading.)
>
> How hard is that to read new releases ?
Same thing, no guarantee about what an actual future operation will do.
By
"would not block", they mean a hypothetical operation taking place at the
time the indication is given to you.
That is, at the instant the determination is made to give you, say, a
'read' indication from 'select', the kernel must believe that had their been
an "appropriate read operation" at the time, it would not block.
Just like 'access' or 'stat', the information is no longer guaranteed
valid
when you receive it. Notice the absence of phrases like 'guarantee' or
'future operation will not block'.
Also, there's no way to tell *what* input operation it's talking about.
For
example, clearly a 'recvmsg(MSG_WAITALL)' *will* block.
The instant case again shows this as well as anything. At 'select'
time, we
believe a 'read' call will not block because there's data. Then at read
time, we discover that things have changed, the data was not application
data but protocol data. So the 'read' blocks because of information
available at 'read' time but not at 'select' time.
Now, had we called 'read' instead of 'SSL_read', we would not have
blocked.
But how can the kernel know at 'select' time what "input function" we plan
to call? Certainly when 'recv' will block is not the same as when
'recvmsg(MSG_WAITALL)' will block.
Again, you don't have the guarantee you need. The standard provides you
a
simple way to get it. You don't do that. That type of reasoning has resulted
in more code breakage than I can shake a stick at.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
