On Wed, Nov 11, 2009 at 6:01 PM, Cathey, Jim <[email protected]> wrote:
>>Why you call the same thing (resetting of O_NONBLOCK)
>>in sh "a fix" and in vi "mangle"??
>
> Because an interactive shell has something of a special
> place in the minds of users. Maybe I could condone it
> gaining a bit of special cleanup code, but no way could
> I back having to change _every_ interactive application
> in the world in order to adapt to an (ill-considered)
> change such as O_NONBLOCK having an effect beyond O_.
Applications which need to do nonblocking reads need to:
(1) try to obtain a non-shared fd; or
(2) clean up after themself; or
(3) switch O_NONBLOCK on/off momentarily before/after read; or
(4) use some other way (poll()? read() interrupted by ALRM?);
* and in any case *
(5) bug standard committees and/or Linux kernel people
to fix the damn mess
I did my part. For example, in runit/svlogd.c I do (3):
static ssize_t ndelay_read(int fd, void *buf, size_t count)
{
if (!(fl_flag_0 & O_NONBLOCK))
fcntl(fd, F_SETFL, fl_flag_0 | O_NONBLOCK);
count = safe_read(fd, buf, count);
if (!(fl_flag_0 & O_NONBLOCK))
fcntl(fd, F_SETFL, fl_flag_0);
return count;
}
And here I tried to do (5) - to propose a kernel-level solution:
http://lkml.org/lkml/2007/8/14/135
Admittedly, I didn't press it to completion (on kernel side,
it would require some non-trivial hacking to do it right,
my patch was a dirty hack).
How about you guys stop pressing for a partial band-aid
being applied and help getting kernel people to see
that this is indeed a real problem in need to fix?
Like, write a (better than mine) kernel patch if you can,
or at least ask for a solution from lkml gurus.
Without this, kernel people just dismiss the problem as
"happens too rarely to be worth fixing".
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
