>>> alarm(1); >>> fgets(buf, sizeof buf, f); > > I was assuming the old standard idiom of installing a do-nothing > signal handler (without SA_RESTART) for SIGALRM so that fgets would > return with an error and the program could proceed.
Ugh. I get it. In this case, then, *of course* you want to get EINTR reported to the user. And I already agreed that the libc should not safe-wrap system calls, so yes, naturally fgets should be interrupted. But honestly, this seems to me like the lazy (in a bad sense) way to write such a program; the right way would be to write a little asynchronous select/poll loop with a timeout of 1 second and a reading event on fd 0. The main reason why the latter paradigm isn't used as much is that stdio doesn't handle partial reads and so is quite unusable in asynchronous loops - in other words, stdio sucks. Whenever I need to listen to signals as events (or, in the case of alarm(), as timeouts), I use a self-pipe and a select loop so I can listen to any number of events at the same time. It's a bit harder to program, but much more robust; the "blocking system calls + EINTR" paradigm is ad-hoc and error-prone. It can break so easily, for instance when your libc is misguided and safewraps around EINTR. ;) -- Laurent _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
