> No, not "they mean", you have no authority to tell what "they mean".
> You have only authority to tell what is your interpretation
> of this text.
> Only authors may tell what "they mean" (are you one of them ?)
What? I presented an argument to show that they must mean this. You
snipped
it.
For example, when they say that 'stat' provides the "size of a file",
when
must the file be that size? It can only mean at some undefined point between
when you called 'stat' and when it returned. You notice they carefully chose
a counterfactual "would" rather than a guarantee "will". That's because the
operation that would not have blocked is one that never takes place.
You get a read hit from 'select' if a hypothetical 'read' operation
would
not block at the instant the read indication is generated. It is not always
clear what 'read' operation is being talked about, since there are many.
> > 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'.
> > Notice the absence of phrase like "hypothetical operation taking
> > place ..."
> > 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.
> What protocol data ?
In the case that caused this whole problem, 'select' gave him a hit on
read. He assumed this meant that a subsequent read operation would not
block. The OS was thinking of 'read' as the subsequent operation but it was
wrong (how could it know?). He was thinking the subsequent operation was
'SSL_read'.
Since 'select' does not guarantee that a subsequent read operation won't
block (since it can't even know what operation that's going to be), the
subsequent read operation (which was 'SSL_read') blocked. That's because
SSL_read blocks for *application* *data* while 'select' checks for *any*
*data*.
You can create many similar instances. All that's needed is the thing
that
'select' checks for to not be *exactly* the same as the conditions that make
the subsequent operation not block. This was the case with the example of
Linux UDP messages, which bit lots of real, actual code that assumed there
was no way exactly this could happen.
> We are talking of pure sockets and select() description (from standard).
> This standard clearly tells of application data, you will not receive
> "TCP flags" from this read().
> You mix information.
Because the 'select' function has no way to know what kind of 'read'
function will follow it, it has no way to assure that that function will not
block. The only well to tell the 'read' function that you are expecting it
not to block is to tell it by setting the socket non-blocking.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
