On Wed, 14 Mar 2012, Rich Felker wrote: > It was cited in "Worse is Better", yes, but I don't entirely believe > the anecdote. SA_RESTART semantics are no harder to implement; it's > just a matter of whether you save the address of the syscall > instruction or the instruction immediately after it when invoking a > signal handler.
Usually the address instruction immediately after will already be on the stack, or some sort of task structure, as part of the normal syscall process that would be followed in the absence of signals. Now, adjusting the saved instruction pointer would not be hard in machine code. Generally, the saved user IP is sitting somewhere in the kernel stack a predictable distance above the return address for the kernel function implementing the call, like a hidden extra argument. But access to such context isn't something C compilers are good at, and the stack offset and syscall opcode length must be customized for each processor family. The ancient worse-is-better Unix programmers probably decided to just foreclose on syscalls doing anything to the userspace registers (aside from the one used to return results). This made the assembly glue joining a CPU-agnostic C kernel to a specific machine as simple as possible, and made EINTR the only acceptable way. > It can be solved (albeit in an ugly way) by having the signal handler > re-arm the alarm with exponential falloff in delay (in case the system > is so loaded that it can't return from the signal handler before > another timer expiration happens). Yuck. That's a lousy quality of implemantion, and isn't even adequate for probing whether a system implements EINTR. > Even if your approach is preferable to users, I don't think it's > conformant, since POSIX specifies the EINTR error for fgetc. Since all That may be just tolerance for a lazy stdio that doesn't work any harder than it needs to. Certainly no one disputes a stdio is *allowed* to treat EINTR same as EIO. The question is whether it *must*. ---- Michael Deutschmann <mich...@talamasca.ocis.net> _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc