Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why is there never much discussion about the actual technical issue presented in the text, which is how to design a syscall API with respect to interrupt handling?

I never thought of the EINTR errno as a hack. It strikes me as very pragmatic and actually the right choice. Am I missing something? Why would one want to save the state of the system call routine when an interrupt occurs and the interrupt handler is executed in user code?

The point of interrupts is precisely that they can interrupt a call that otherwise could potentially block forever. When an interrupt occurs, the user code has the chance to completely cancel any attempts to complete the original call. Otherwise, just re-try. The complexity added to the syscall API is small, the practical benefit is very real.

So why would I want a general mechanism in the kernel that automatically continues the blocking call after running the interrupt handler?

To me the lesson from "Worse is Better" has always been "Don't design before you actually know what you need. You'll probably end up with something that does not do what you want and that you can't fix".



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: