David Schwartz wrote:
No. That you cannot think of a way does not mean that no way exists.
WTF ! Is dark the absence of light, or is light the absence of dark ?
Please prove your way exists, there are enough poll/select
implementations available to inspect. Your words have no weight without
any proof.
People thought that if they got a write hit from select, they could then
call write without blocking. Oops, if the write was too big, they blocked.
They couldn't think of a way, but they were not *guaranteed* there was no
way. (And there are lots of ways this breaks on non-standard implementations
too, like systems with small buffers when the other side shrinks the
window.)
Generally speaking in the application programing paradigm we are talking
about we WANT writes to block. When we are writing we are busy doing
something for the peer at the other end. But when we are reading we are
idle and waiting for the other end to give us something to do but are
unsure what.
This plays directly into a central idle event loop driven by poll/select
but when we are writing we have usually handed off to a specialized
function within the application to do that specific task. The simple
design of the program allows control to be where the application
developer needs it.
It is probably the desire for blocking writes that compels the
programmer to elect a blocking socket programming paradigm over a
non-blocking socket paradigm.
People thought that if they got a read hit on a listening socket, they
could then call accept without blocking. Oops, if the connection terminated
before they called accept, they blocked. They couldn't think of a way, but
they were not *guaranteed* there was no way.
Transport level accept() are again out-of-scope of the discussion at
hand. Thanks for your schooling on sockets but your fundamentals need
more work.
I mean you would have through if you put an accept() socket into
non-blocking mode, then the new sockets it created would inherit that
non-blocking mode too. But it don't. Nice info but completely
unrelated to the issue being discussed.
This is how subtle bugs and corner cases bite you on the ass. You assume
that because you can think of no way to break something, it is guaranteed to
work. That's not how it works. It's guaranteed to work if the relevent
standard provides such a guarantee.
Where is your specifications / standards on poll() or select() ? Does
XOPEN, IEEE, POSIX or BSD mandate behavior ? In the absence of a
specification and a relevant test certificate in hand you are left with
proving your claim with an implementation. That will do me :) Can you
please point at that implementation.
Now, you could have a guarantee and it still not work due to thinks like
bugs or trade-offs that technically violate the standard but where someone
thinks that's not so important. But this weighs even more strongly in favor
of my point. It is trivial to avoid these bugs and corner cases by selecting
non-blocking behavior.
We're getting away into chaos theory now. The butterfly that breaks
wind in china, causes the earth quake in the antarctic.
I've ~15 years experience in unix socket layers, yes my first 3 years
were full of programming errors but I'm all better now.
As for your example with write() -- of course a write of 20Mb might
block, but we are not talking about write(), we are talking about
read().
They do have different semantics. Same goes to your mentions of accept().
Only because people *discovered* that they do. How can you say nobody
will
later discover this about 'read'? Say someone adds an extension to TCP to
allow one side to 'revoke' data that has not been read yet by the other
side. Are you going to argue that they cannot do this? Or that POSIX
prohibits it?
WTF. We're out past Mars now. We're guarding todays code from
hypothetical future protocol extensions that might break it. W.T.F.
Don't you think the people who invent the next crazy idea didn't think
about the whole problem much better than you and I, and you know lots.
I can almost guarantee the existing behavior will not change with any
new extensions. Just think how are you going to get the zaney idea past
all those standards committees. If its a bad idea darwin will prevail.
Well yes POSIX probably will prohibit it, as in the commitee will
reject it; you think everyone on the POSIX commitee is going to say yes
to a new thing which breaks multi-million investments in codebases. I
think not.
Suppose we are using SSL over a protocol that has sophisticated timeout
detection. It detects a timeout and indicates that at that instant a read
will not block (reporting connection close). But then, just before we call
read, it gets the data it was waiting for. It then decides the connection
does not need to be closed since the close was never received or
acknowledged by the application. Now the read blocks.
Euh? Can you draw me a picture ?
Are you saying such a protocol cannot exist? Or that 'select' cannot
work
with such a protocol? Or that OpenSSL should break on such a protocol?
Euh. If your application design is complex non-blocking mode allows you
to do anything. Think of restartable non-blocking mode as being the
most primitive building block to write any model you like on top of it.
The problem here is how a classic network application design model with
both with and without OpenSSL involved.
We are not on some crusade to say that you must use a blocking socket
model. Both models have their strengths and weaknesses, non-blocking is
more complex, blocking is less complex. You do however appear to be one
some sort of crusade against.
This same argument would apply to any protocol that can report non-fatal
errors. You think POSIX designed 'poll' and 'select' to make non-fatal
errors impossible?
Euh.
A non-fatal error, these are conditions which are part of the normal and
expected working of the resource:
* End of Stream/File
* No Data available EAGAIN
* Signal interrupted us EINTR
A Fatal Error is, these are unexpected, catastropic errors relating to
the resource:
* EBADF
* EINVAL
* EFAULT
We have a method that is guaranteed to work -- making the socket
non-blocking.
We are not denying this isn't factually correct.
I mentioned threads not to argue that another thread might read the data
but to show that it's impossible for select to make a subsequent operation
non-blocking because there is no reliable way to pair select operations with
subsequent operations.
You know its impossible for me to know for sure if my data is being
stored correctly; when I write a program to add 1+1 and store the result
in my variable "int Global_foobar;" This is because some internet
script kiddy might have been able to hack into my computer, gain root
access and be running a debugger on my process. And just when I went to
store the integral result (that is TWO) into the global variable; he
changed the value to FOURTY TWO. So everytime I look at the memory
location the value is all wrong.
So how can I go one programming knowing this ? Its the end of my world,
the sky is falling in.... I'm going to ... J...U....M.....P.....!!!!!!
However, it is a serious error to promote bad programming practice by
pretending that you can use 'select' or 'poll' to ensure that a future
operation on a blocking socket will not block. You simply cannot do this. It
does not and has not ever worked.
Your belief is incorrect. The application works fine without OpenSSL
with exactly the same programming paradigm.
You've been most entertaining to poke fun at :)
Find me some coded proof or write a program to demonstrate the behavior
you believe in.
Have a nice day.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
