> > If anyone thinks that 'select' or 'poll' guarantees that a
> > future operation
> > will not block, even if it's a single operation, that's just
> > plain not true.
> > The only way you can guarantee that even one operation will not
> > block is if
> > you set the socket non-blocking.
> Really.
>
> I dont think the IEEE and POSIX specifications are publicly available to
> quote you an extract.
They talk about a hypothetical operation and whether or not it would
have
blocked.
> However the Linux man page talks in those
> specific terms of a descriptor becoming writingable means that a write
> operation will not block (I think its widely accepted that they are
> referring to only the next single invocation of write() will not block).
If that's what they're referring to, they're obviously in error. If the
next write, for example, is for 982,320 bytes, it most certainly *will*
block if the socket is blocking.
> Maybe you can show me your standards that cover the select() system call
> you have ? What standards are you working to ? If there are no
> standards maybe you can demonstrate an implementation of the select/poll
> system call that doesn't work that way. Then explain how normal
> blocking IO on sockets works on that platform (including interaction
> with signal handling, transport layer errors, buffers becoming full,
> etc..). I'm pretty sure form that all I can describe to you how OpenSSL
> would work for that platform in that situation.
The return value from a 'select' call does not guarantee any future
results, nor could it. That would insanely require the operating system to
remember that you got some information from 'select' and modify the next
blocking operation to be non-blocking. How this would work in a
multi-threaded case is quite puzzling. If thread 1 gets a write hit from
select, then thread 2 tries to write 192,903 should it block or not? How can
the implementation know whether the write from thread 2 is expecting the
'select' information thread 1 got to mean it shouldn't block?
That's crazy. If you want non-blocking behavior, the only thing that
assures it is non-blocking sockets.
For example, SuSv2 documents 'select' like this:
http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
Search it for the phrase 'block' and you will see lots of stuff about
when
and how 'select' blocks but nothing about some future operation not
blocking.
> I'm thinking along the lines of transparency of that platforms blocking
> socket IO model, and less black magic voodoo (which only bite developers
> in the ass).
There are just too many corner cases. It is simply not possible to
assure
that you will never block if you perform operations on blocking sockets.
> In a way its cheeky of you to be asking for standards to backup the
> syscall as if it has any bearing or weight in this thread. The thread
> comes from the more practical approach of how systems are and how
> implementations are of existing application software. The request is
> just for the operating systems blocking design paradigm to be maintained
> through to the high level SSL API calls (SSL_read()/SSL_write()) etc..
> It would be true to say that if the platform doesn't support the
> poll/select blocking socket paradigm we are expecting then that program
> (you are adding OpenSSL) won't be written in that way. This makes what
> the exact specification of poll/select is in relation to blocking IO
> irrelevant, we just want transparency of whatever that model is at
> syscall level on that platform brought out to the SSL API calls.
I agree with you. My position is that SSL_read should behave just like
read, blocking until it can return data to the caller. A blocking 'read' or
'SSL_read' must only be made when you *know* there will be data to be
returned.
> So there is no point in getting tangled up on the topic of select/poll
> syscall specification.
Well, if the argument is that 'SSL_read' should have different semantics
from 'read' because doing so is needed to allow you to assure that you will
never block even if you use a blocking socket, it is important to show that
you do not have this guarantee with 'select' and 'read', so the fact that
you don't have it with 'select' and 'SSL_read' is not a semantic difference.
(Just a legal corner case that happens much more frequently.)
The error is this simple -- you cannot call 'read' on a blocking TCP
socket
or 'SSL_read' on a blocking SSL socket unless you *know* that there is
appplication level data to be returned or you may risk blocking forever, any
possible return value from 'select' or 'poll' notwithstanding. (Because
'select' and 'poll' *never* guarantee what a future operation will do. POSIX
does not say so. SuS does not say so.)
The Linux man page seems to say so, and I don't know if it's simple
error
or just bad phrasing. For example, does "will not block" mean will not block
in a subsequent operation? If so, it's wrong for many well-known corner
cases if the socket is blocking. (For example, 'accept' if the connection is
closed before it's accepted, 'write' if the number of bytes is sufficiently
large.)
However, what I think it means when it says "will not block" is not an
actual future operation but a hypothetical concurrent operation. This
mirrors the early standards efforts that talked about some hypothetical
operation that "would not block" (had it been issued concurrently with the
'select' call).
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
