Re: non blocking sockets
From: David Schwartz (davids_at_webmaster.com)
Date: 07/27/04
- Next message: Lev Walkin: "Re: pipe of size 1"
- Previous message: joe_at_invalid.address: "Re: non blocking sockets"
- In reply to: joe_at_invalid.address: "Re: non blocking sockets"
- Next in thread: joe_at_invalid.address: "Re: non blocking sockets"
- Reply: joe_at_invalid.address: "Re: non blocking sockets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 26 Jul 2004 20:49:29 -0700
<joe@invalid.address> wrote in message
news:m3r7qymhsi.fsf@invalid.address...
> Barry Margolin <barmar@alum.mit.edu> writes:
>> In article <m3zn5mmp6n.fsf@invalid.address>, joe@invalid.address wrote:
>>
>> > However, what the standard *says* is that it won't block. Whatever
>> > you want to say blocking is or isn't, the standard says it won't.
>>
>> The standard doesn't say "won't block", it says "wouldn't block".
>> I.e. it wouldn't have blocked at the time that select/poll
>> determined that the socket was ready.
>
> Well, maybe I'm missing something, but this is what I see:
>
> Upon successful completion, the pselect() or select() function shall
> modify the objects pointed to by the readfds, writefds, and errorfds
> arguments to indicate which file descriptors are ready for reading,
> ready for writing, or have an error condition pending, respectively,
>
> The "shall" in that sentence indicates to me a guarantee that the
> contents of the fd_set objects indicate whether or not the descriptors
> are ready for reading, writing or have an exceptional condition
> pending. Those contents are not available until after select returns.
I'm sorry, that's utterly absurd. You might as well argue that 'stat'
guarantees that the size of the file can't change since you can't access the
size until after 'stat' returns and standard says that 'stat' shall return
the size of the file.
> Being ready for reading is further defined as:
>
> A descriptor shall be considered ready for reading when a call to an
> input function with O_NONBLOCK clear would not block, whether or not
> the function would transfer data successfully. (The function might
> return data, an end-of-file indication, or an error other than one
> indicating that it is blocked, and in each of these cases the
> descriptor shall be considered ready for reading.)
>
> I understand this to say that whether or not a descriptor is ready for
> reading isn't determined by some unknowable state before select
> returns, but by the values in the fd_set object *after* it returns.
I don't understand your understanding. Are you saying that the
implementation is prohibited from changing the state of the socket after
'select' returns? Until when?
> If the values in the fd_set objects are to be considered out of date
> when they return, why would the standard define the values of those
> objects to be the indicators of whether or not a read operation will
> block?
Because that's how every other function works. Why does 'stat' return
the size of a file if that might not be the size by the time you get around
to checking it?
>> The standard is meant to be read by people who are knowledgeable in
>> the design of operating systems. We know that blocking is based on
>> dynamic state, so it doesn't make sense to interpret the
>> specification as anything other than a claim about a potentially
>> transient property of the socket.
> I always thought the purpose of standards was to define the behavior
> of what's being standardized, so that people could design and program
> to a predictable way of doing things.
You two are not disagreeing with each other. You are just assuming that
a guarantee exists when it does not. It's well known that the return value
of functions can be out of date by the time you get around to noticing those
values.
DS
- Next message: Lev Walkin: "Re: pipe of size 1"
- Previous message: joe_at_invalid.address: "Re: non blocking sockets"
- In reply to: joe_at_invalid.address: "Re: non blocking sockets"
- Next in thread: joe_at_invalid.address: "Re: non blocking sockets"
- Reply: joe_at_invalid.address: "Re: non blocking sockets"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
