> On Thu, 22 Jun 2006, David Schwartz wrote:
> > Bingo! And work may or may not translate into application data.
> I thought that a recv on a blocking socket returns immediately after it
> was able to do some work, no matter whether it resulted in receiving any
> actual data (e.g. socket closed). If a blocking call managed to do
> something it should return. If a blockig SSL_read call managed to finish
> the negotiation but didn't get any app data it should return.
Do you know of any implementation where this is the case? For example, I
call 'read'. There is no data, but a TCP window advertisement is sent. Work
has been done, should 'read' return? If so, *what* should it return?
EWOULDBLOCK?!
I really wish that were the way things were defined from the beginning.
That would make a lot of things much simpler. It would mean that all
blocking applications always had to check that work of the particular kind
they wanted was done, but that simplifies things enormously. (And they
pretty much have to do that anyway. Short writes are possible. Empty reads
are not as far as I know.)
However, even if this is true, it still doesn't change the basic issue
here. You don't have the guarantee you think you have. Even if you construe
'select' as guaranteeing at the time the hit is generated that work can be
done, it does not follow that work can be done later. So you could still
block.
This really is an error akin to checking 'access' or 'stat' and assuming
that whatever information you got will still be valid by the time you come
back to doing something else. It's wrong even when you can't think of
anything that could change it in the meantime and it's right only when
you've assured that nothing could possibly change it in the meantime.
It would be nice if they had defined 'select' as a hint that you should
retry. It would be nice if they had defined 'read' as returning when work
has been done and made 'EWOULDBLOCK' a legal return on a blocking socket. It
would be nice if people wrote defensive code that didn't break in corner
cases because they relied on guarantees they didn't have that break in
strange and subtle ways when their code is used outside its design
environment.
Reality is what it is. What bothers me here is that people are
specifically
advocating this type of coding on no stronger grounds than that they can't
think of any way it can break on any current implementation when this whole
thread started because it broke. (The application did not anticipate a
transport that can carry both application and non-application data.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
