Hi,
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
* Yves Rutschle wrote on Mon, Aug 27, 2007 at 16:10 +0200:
> On Sat, Aug 25, 2007 at 12:47:57AM -0700, David Schwartz wrote:
> > > Yes? If so, the above paragraph or something similar
> > > should be documented somewhere important (e.g. the
> > > manpages).
> >
> > That's one way to put what I'm saying. I agree it needs to be
> > repeated more often, that's one of the reasons I repeat it as
> > often as I can.
>
> I'm afraid it's worse than just the man pages.
>
> After thinking for a fleeting moment that what you were
> saying made no sense, then thinking some more and thinking
> it did make sense, I went back to my standard bible
> "Advanced Progamming in the Unix environment" (Stevens &
> Rago), which actually explicitely states ("select and
> pselect functions", p475):
>
> "With [select's] return information, we can call the
> appropriate I/O function (usually read or write) and know
> that the function won't block."
>
> I guess this should read "call the I/O function and know it
> wouldn't have blocked if we'd called it instead of calling
> select".
(with the exception that select may `delay' or timeout of course)
I think it is important to note that a blocking read usually
should return if one single byte is available (even if more had
been requested) and a blocking write should return as soon as at
least one byte has been written. Of course, at least for
performance, read and write should attempt to read or write as
much as possible :-)
Is this correct?
Also worth to be mentioned may be that the discussion is about
guarantee to return (i.e. non-blocking call), not to return the
requested data (or even any data). Especially, it is not
guaranteed that the call will work, it may fail returning an
error (right?).
> > > Not every day I learn something new. Though I'm slightly
> > > horrified because my code base is extensive and I do quite
> > > a bit of socket programming...and I've been doing it wrong
> > > for about 7 years. This is apparently going to be a LONG
> > > weekend.
>
> If even the reference litterature gets it wrong...
I think, this also depends whether taking this as documentation
or specification. I could imagine to implement some subsystem
fulfilling such a guarantee, because in case the situation
changed (which is, that the return value of select or the status
reporting function has changed without any call in between) an
error could be returned. Theoretically, in the file size example
a `error file truncated' or so could be possible.
For buffered communications, I assume, this should always be
possible. If there is data stored in some internal buffer (making
select returning `ready for reading'), this data must be readable
or an error must be returned. I would consider the loss of the
data from such an internal buffer an error which should be
reported (instead of blocking). `ready for writing' in such a
subsystem would mean that some write buffer has at least one byte
free and thus the next write call can return (without blocking).
If it cannot be written for any reason I think a nice
implementation should return an error in this case.
I understand select as a call to (more or less) report the state
of some internal communication buffers and expect to make
guarantees about those buffers (no concurrent threads etc of
course).
In the file size example, I expect read to return 0. I made a
small test program and on linux (accidently?) it does not block
when reading a truncated file (actually, select even returns
`ready for read' on an empty file).
Probably I simply did not understood what David explained. He
told that it cannot be guaranteed that a read or write call will
not block. Unfortunality I don't know anything about the accept
related DoS. For the file and UDP examples, I would expect read
to return 0.
David, do you mean `it cannot be guaranteed because no
implementation can be guaranteed to be 100% correct and may fail
in a complex situation' or do you mean `it cannot be guaranteed
logically/theoretically, even if the implementation is assumed to
be 100% correct, because of a logical dilemma'?
oki,
Steffen
About Ingenico Throughout the world businesses rely on Ingenico for secure and
expedient electronic transaction acceptance. Ingenico products leverage proven
technology, established standards and unparalleled ergonomics to provide
optimal reliability, versatility and usability. This comprehensive range of
products is complemented by a global array of services and partnerships,
enabling businesses in a number of vertical sectors to accept transactions
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
About Ingenico Throughout the world businesses rely on Ingenico for secure and
expedient electronic transaction acceptance. Ingenico products leverage proven
technology, established standards and unparalleled ergonomics to provide
optimal reliability, versatility and usability. This comprehensive range of
products is complemented by a global array of services and partnerships,
enabling businesses in a number of vertical sectors to accept transactions
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
