kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances

[Konstantin Belousov]

On Tue, Jul 10, 2012 at 06:02:50PM +0300, Volodymyr Kostyrko wrote:
> Konstantin Belousov wrote:
> >>So you mean this is just my false assumption that EOF _should_ occur on
> >>stdin? And it actually occurs only if source is a process which can send
> >>EOF?
> >
> >'Source' cannot be a process. Read filter on pipes can return EV_EOF.
> >Read filter on vnodes (read: regular files) does not return EV_EOF,
> >except in situation that is created by manual intervention of
> >administrator.
> 
> This keeps me puzzled. How then I can tell that file at stdin is already 
> at EOF? You mean I should treat stdin like normal vnode-backed file?
> 
>   off_t pos = 0, endpos;
> 
>   lseek(fileno(stdin), 0, SEEK_END);
>   endpos = ftell(stdin);
>   lseek(fileno(stdin), 0, SEEK_SET);
> 
> ... and then later check it with:
> 
>       if(endpos != -1) {
>         pos += kev.data;
>         if(pos >= endpos) {
>           printf("end reached\n");
>           return(0);
>         }
>       }
> 
> Is this a correct way to detect EOF? I'm letting besides that I should 
> also detect vnode changes and update max file size accordingly.
> 
> >It should have been clear from my previous response.
> 
> Please excuse me, I'm a bit new to this things...

Why do you use kqueue there at all ? Just read from stdin, and decide
that you hit EOF when read returned 0 bytes.

If insisting on using kqueue, which may be ligitimate if you process
other sources besides stdin, you should first investigate the nature of
the fd 0 using fstat, and then use appropriate code for regular file,
pipe and probably socket (e.g. for the case if code allows to run under
inetd(8)).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120710/7b6a614c/attachment.pgp