* Bill Studenmund <wrstuden@netbsd.org> [031112 12:27]:

> > I'm not sure I understand what is the exact issue.
> 
> I'm only responding to the notes also.
> 
> > Why would this be necessary or what does this exactly solve? AFAIK
> > poll() doesn't set any flags in this case neither, so I don't
> > see how this is inconsistent.
> 
> I think the difference is in the default behavior. When you're at EOF, I 
> know that poll() will give you a read-availability event, so you'll read 
> the EOF. Will kqueue?

correct - this is the difference, kqueue will not yield any event at
EOF.

> > BTW, shouldn't the EOF flag be cleared when the file is extended?
> 
> Probably.

i'm not sure this is an issue - at the point where EOF is determined,
the kqueue event returns success.  and in this case, the event is
always successful, so the process will not sleep on the kevent() call.

in a preemptible kernel, there is a race between the EOF condition is
determined and kevent() actually returns.  semantically, in this case
it makes sense to cancel the event (for which there is no
infrastructure), and not necessarily clear its flag.  though in this
case, that hack will work correctly.

marius.

-- 
marius a eriksen <marius@monkey.org> | http://monkey.org/~marius/