On Fri, Sep 3, 2010 at 9:20 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > So we now have the same process nested twice inside a semop() call. Looking > at the Linux signal (7) man page, it is undefined what happens if semop() is > re-entered in a signal handler while another semop() call is happening in > main line of execution. Assuming it somehow works, which semop() call is > going to return when the semaphore is incremented? >
Fwiw I wouldn't be too worried about semop specifically. It's a syscall and will always return with EINTR. What makes functions async-unsafe is when they might do extra processing manipulating data structures in user space such as mallocing memory. POSIX seems to be giving semop license to do that but realistically I can't imagine any implementation doing so. What I might wonder about is what happens if the signal is called just after the semop completes or just before it starts. And someone mentioned calling elog from within the signal handler -- doesn't elog call palloc() and sprintf? That can't be async-safe. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers