Hello, > > 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. 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 ?)
> 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 ? 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. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
