bd72d115
From: m@rtij.nl.invlalid
On Sat, 27 Feb 2010 13:59:28 -0800, David Schwartz wrote:
I respect your opinions, you are way more knowledgeable than I am in this
field. However, I still don't get it, and most of your arguments don't
even make sense to me.
> On Feb 27, 1:03 am, Jorgen Grahn wrote:
>
>> > POSIX is really quite clear that it doesn't make such a guarantee. It
>> > is quite clear that 'select' simply reports current status and that
>> > it does not guarantee future results. It uses very natural
>> > terminology to do this.
>
>> In that Linux kernel mailing list thread mentioned above, everyone (or
>> possibly just almost everyone) seemed to disagree with your
>> interpretation. Even the big group (including several well-known
>> programmers) who thought little of POSIX and like you recommended
>> O_NONBLOCK sockets.
>
> I don't understand their position. It's really this simple -- UDP
> datagrams can be discarded.
Can UDP datagrams be discarded after select has indicated one is waiting?
Is there any OS that really does this?
>
>> > For example, one could describe a successful return from "access"
>> > checking readability as meaning that an attempt to open the file for
>> > reading wouldn't fail with a permissions error. But this in no way
>> > implies that an actual subsequent open will not in fact fail.
>
>> That one is immediately obvious, because it's not talking about
>> resources/state owned by the process.
>
> Neither is 'select', since the state of a connection is shared by the
> process and the other side of that connection.
Is it? If select indicated a socket as ready, can the other side change
that? (Note that closing the connection also means the socket is ready).
>> >> 'The Linux developers believe that the use of select() with blocking
>> >> file descriptors is invalid or not recommended, and have chosen not
>> >> to ensure that this use of system calls is reliable.'
>
>> > Consider:
>>
>> > 1) Thread A calls 'select', gets a writability hit for socket 12.
>>
>> > 2) Thread B calls 'write' on socket 12.
>
>> That one was used on the LKML and refuted, too. People who do such
>> things get what they deserve (and I'm not even sure I care what POSIX
>> has to say about it). You'd need an example which doesn't involve
>> multiple threads sharing fds without synchronization.
>
> The example is exactly the same if it's one thread. I only picked two
> threads for clarity.
If there is one thread, the second read is just that, the second read.
And with two threads this is exactly the same. As we are talking about
the first read, I don't see how this is relevant.
>
> The point is, there is no way the kernel can tell if a 'select' call
> followed by some socket operation are logically dependent or logically
> independent. Any claim that the 'select' changes the semantics of the
> followup call requires that there be some unambiguous way to identify
> whether a particular call is or is not a followup call. And that is
> impossible.
>
> Consider:
>
> 1) The state of a socket is such that a certain won't block.
>
> 2) The application calls 'select'. The application must get a read hit.
> It does.
>
> 3) The state of the socket changes such that this operation *must*
> block. That is, POSIX guarantees that the operation will block when the
> socket is in this state.
But HOW can the state of the socket change at this point? All examples so
far are either under application control or need some substantiation.
M4
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
