Re: pipe write buffer

davids@xxxxxxxxxxxxx wrote:

No David, you're on the wrong trail here...
Please explain why.

See below...

select() / poll() have indicated that a read() recv() ... call can be
made WITHOUT blocking (even if the fd in used is in blocking mode).

No, not "can be made", "could have been made". The indiciation is
correct at the time it is generated, but becomes stale as soon as your
code gets it. This is the same for every other indication provided by
every other function, 'stat', 'access'. It is a bug to assume that it
must be true later.

This is a guarantee to the process not only for a few milliseconds.
Its the kernels responsibility to maintain an appropriate state on
this fd until the application finds time to care for this, even
if it takes five years (so to say).

No, it is not. POSIX does not say this and it defies common sense. You
might as well say that if I 'stat' a file, the kernel shouldn't let
another process delete or modify that file just in case I plan to
follow the 'stat' with some other system call that relies on the
response from 'stat'. It's nonsensical.

An implementation failing to do so simply has an error!

Nope.


Ok let's have another look at it...

The problem boils down to wether poll() select() deliver "static" information or wether they deliver a snapshot from state at call-time
(which is subject to change without notice).

Additionally, you claim, that no standard tells that poll() select()
musts deliver static results.

To simplify things ... let's exclude the whole problematic with
"multiple readers callin read after poll/select" because the
problem here is build up in userspace (and can be solved there)
whereas the other is in kernelland. This also excludes your
argumentation with the stat() call. (Because if I'm the only one
to modify a file I can assume the file to have the properties stat()
was telling me in a call.)

So, what would happen to us, if poll() select() where allowed to
deliver snapshot-information (that can change state in the time between
select() and read/write)?

1) Usage of fd's with blocking IO is a complete NONONO.

Why? Because your process can be blocked in read() write at any time
even if a previous poll select where telling (in this case only
pretending) the call wouldn't block.
Multiplexing of fd's with fd's left in blocking mode would
actually be impossible. The poll() select() calls would be rendered
completely unusable, if you could only expect the information to be
a snapshot.

2) Usage of fd'd with non-blocking IO is not much better.

Why? Because we cannot prevent our process from falling into
a busy loop! Noting is preventing a "poll POLLIN read EAGAIN" loop.
If poll only deliveres a snapshot, a system that was idle in
one second can become completely overloaded within a second with
tousands of runable processes that do not do any usefull work
anymore. Even trating EAGAIN/EWOULDBLOCK as an error after POLLIN
(as I usually do) will not help much, because this will only change
the loop-content a bit ...
"poll POLLIN read EAGAIN close create_newsocket"

So the definition that poll() select() will give us only a snapshot-like
result is not helpfull at all. With this definition it becomes
impossible to write stable code.

Being part of a standard or not, the only mode that makes sense
if you think about it, is the static mode, where a state has to
be maintained until the process reacts on the state with a call.


Finally, I think this thread is not on-topic for too long and should
be terminated here ... I think the arguments are exchanged, and
I'm not going to contribute much more.

And, David, wether you think I'm "making this all up" as you
wrote in your last message or not, is something I really
don't care much about. To write it to usenet might be a bit off-road
of common accepted netiquette.

Rainer


.

Relevant Pages

  • Re: blocking read/write in socket
    ... If you have a blocking socket, and select(or poll()) says it is ... In the absence of errors and signals, a blocking writewill write the ... set it will just waste CPU time looping whereas using selector poll ...
    (comp.unix.programmer)
  • Re: 8ms Timer for serial port access
    ... You can use 'poll' to tell when there's data ready ... >> 3) Repeat. ... >> 2) Read as many bytes as are ready without blocking. ... > Then I will have another delay before I can process the data. ...
    (comp.os.linux.development.apps)
  • Re: pthreads for serial programming
    ... > Can you make the file descriptor non blocking using ioctl? ... > you tried using poll with a timeout before the read? ...
    (comp.programming.threads)
  • Re: kqueue alternative?
    ... >>don't support kqueue? ... I'd really hate to poll with stat(), ...
    (freebsd-hackers)
  • [PATCH] sysfs: Make poll behaviour consistent
    ... was previously set to zero. ... also zero, so poll was blocking, regardless of whether the attribute ...
    (Linux-Kernel)