> 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.
I hate to be rude, but do you understand *anything* about programming to
standards? The 'select' and 'read' functions are standardized, as is
blocking and non-blocking I/O. You have the guarantees specifically
enumerated in the standard and cannot assume things not assured because
future implementations might violate those assumptions.
> 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.
> > 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.
What the hell are you talking about? The relevent standard sections have
been pasted. They do not guarantee that a future operation will not block. I
explained why they cannot do so. What more do you need?
> 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.
Glad to hear 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.
That is how you write good programs. You assume only what is guaranteed
by
the specifications because you know that future implementations will be
different. All it takes to break your code is an error condition that can
clear, say due to packets being received.
> 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.
How is this an argument for making code more fragile by relying on
guarantees that don't exist? "Well, it will break a lot of stuff, so
creating a few more things that will break is okay." That's how you wind up
with a *lot* of broken code when things really have to change.
> 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.
I am not against blocking socket models, they just block. Sometimes
that's
appropriate, sometimes it's not.
What I am against are half-assed models that usually don't block, are
required to never block, but might block if the unexpected happens. Then the
unexpected happens as it did in this very case, and the application breaks.
This is a precise case of the very breakage you insist cannot happen.
The
'select' call gets a read hit because data is available. Later the
implementation changes its mind when on closer inspection it appears the
data is not the right data to satisfy the 'read'. So the 'read' blocks.
You claim this can never happen when IT JUST DID. The reason we are
having
this conversation is because we found a case where the assumption breaks --
when the transport can hold both application and non-application data.
Yet you still claim it can never happen. I'm baffled.
> > 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
Consider. A non-fatal error occurs on a stream, say a timeout. You get a
'select' hit on read because at that instant a 'read' will not block. Then,
the error clears, maybe the waited for packet is received. So when you call
'read', there is no error and no data -- it blocks.
Please show me where the standards for 'select' and 'read' guarantee
that
this cannot happen. You cannot do it.
> 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.....!!!!!!
I discussed this, it supports my view of coding safely rather than
relying
on guarantees you don't have. Any bug or glitch is more likely to result in
unexpected blocking.
I can give a concise example. Linux used to check the checksum on
received
UDP packets at 'read' time. If you got a packet with a bad checksum, you
would get a 'select' hit. But at 'read' time, you'd block because there was
no *valid* packet. You can argue that this is a violation of the standard,
because at no time would a 'read' ever have not blocked. However, the
workaround is precisely what I'm saying, use non-blocking sockets if you
want non-blocking behavior.
However, in this case, we have standards that provide us sufficient
guarantees to write code that's guaranteed by the standards to work. Relying
on the guarantees that we imagine are there but are not has broken code in
the past and is breaking the code we are now talking about.
> 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.
For the love of god, this whole thread started because of a program that
demonstrated the behavior I "believe in". Actual programs have broken
because of corner cases.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
