Martijn van Oosterhout <klep...@svana.org> writes: > If the issue is just that select() doesn't get interrupted and we don't > care about a couple of syscalls, would it not be better to simply use > sigaction to turn on SA_RESTART just prior to the select() and turn it > off just after. Or are these systems so broken that select() won't be > interrupted, even if the signal handler is explicitly configured to do > so?
I think you mean turn *off* SA_RESTART. We'd have to do that for each signal that we were concerned about allowing to interrupt the select(), so it's more than just two added calls. Another small problem is that the latch code doesn't/shouldn't know what handlers are active, and AFAICS you can't use sigaction() to flip that flag without setting the handler address too. So while maybe we could do it that way, it'd be pretty dang messy. In my mind the main value of the Latch code will be to have a clean platform-independent API for waiting. Why all the angst about whether the implementation underneath is clean or not? It's more important that it *works* and we don't have to worry about whether it will break on platform XYZ. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers