muszę listę asynchroniczny sygnał bezpieczny funkcji z glibc

Question

owijarki

Non syscall, ale coś podobnego snprintf(), dprintf()

Answer 1

Wreszcie najnowsze wersje man 7 signal-safety zawierać zainteresowanych listę: signal-safety.7.html

Answer 2

Jestem całkiem pewien, trzeba zobaczyć documentation

Edycja: A co powiesz na this list?

Od man signal:

NOTES 

    The effects of this call in a multi-threaded process are unspecified. 


    The routine handler must be very careful, since processing elsewhere 
    was interrupted at some arbitrary point. POSIX has the concept of "safe 
    function". If a signal interrupts an unsafe function, and handler 
    calls an unsafe function, then the behavior is undefined. Safe func- 
    tions are listed explicitly in the various standards. The POSIX.1-2003 
    list is 

    _Exit() _exit() abort() accept() access() aio_error() aio_return() 
    aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed() 
    cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect() 
    creat() dup() dup2() execle() execve() fchmod() fchown() fcntl() fdata- 
    sync() fork() fpathconf() fstat() fsync() ftruncate() getegid() 
    geteuid() getgid() getgroups() getpeername() getpgrp() getpid() getp- 
    pid() getsockname() getsockopt() getuid() kill() link() listen() 
    lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe() 
    poll() posix_trace_event() pselect() raise() read() readlink() recv() 
    recvfrom() recvmsg() rename() rmdir() select() sem_post() send() 
    sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid() 
    shutdown() sigaction() sigaddset() sigdelset() sigemptyset() sig- 
    fillset() sigismember() signal() sigpause() sigpending() sigprocmask() 
    sigqueue() sigset() sigsuspend() sleep() socket() socketpair() stat() 
    symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetp- 
    grp() tcsendbreak() tcsetattr() tcsetpgrp() time() timer_getoverrun() 
    timer_gettime() timer_settime() times() umask() uname() unlink() 
    utime() wait() waitpid() write(). 

    According to POSIX, the behaviour of a process is undefined after it 
    ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by 
    the kill(2) or the raise(3) functions. Integer division by zero has 
    undefined result. On some architectures it will generate a SIGFPE sig- 
    nal. (Also dividing the most negative integer by -1 may generate 
    SIGFPE.) Ignoring this signal might lead to an endless loop. 

    See sigaction(2) for details on what happens when SIGCHLD is set to 
    SIG_IGN. 

    The use of sighandler_t is a GNU extension. Various versions of libc 
    predefine this type; libc4 and libc5 define SignalHandler, glibc 
    defines sig_t and, when _GNU_SOURCE is defined, also sighandler_t. 

Answer 3

To wydaje się trudne do określenia, ponieważ nie wiem, co funkcja losowa niebezpieczne rutynowe biblioteki może zdecydować się połączyć. Lista może również różnić się w zależności od wersji glibc lub jeśli zostanie przeniesiona do innego systemu podobnego do systemu Unix. Wygląda na to, że musisz przeanalizować wiele stosów wywołań, aby znaleźć odpowiedź, a nawet to może być trochę chwiejne od wersji do wersji, distro do distro.

Może nie szukasz alternatywnych podejść do projektowania, ale wygląda na to, że lepszą strategią byłoby: jeśli Twój program ma pętlę zdarzeń, uczyń obsługę sygnału bardzo głupim i po prostu ustaw stan, że pętla zdarzeń podniesie . W ten sposób wykonujesz znaczącą pracę poza obsługą sygnału.

Przykład: Załóżmy, że masz gdzieś pętlę poll(). Być może mógłbyś dołączyć rurkę, do której może prowadzić program obsługi sygnału. Pętla poll() wykonuje pewne nietrywialne działanie w oparciu o zasygnalizowanie tego.

Answer 4

Potrzebuję tego w module obsługi SIGSEGV PO awarii aplikacji.

Chcę rozwijać stos o katastrofie

Jeśli próbujesz uchwycić ślad stosu:

• Zazwyczaj abort spowodowałoby zrzut rdzenia, który może zostać uruchomiony przez debugger do wygenerować ślad stosu.

• Alternatywnie, surowy (ale sygnał-safe) sposób robić to byłoby fork i exec oddzielne narzędzie (na przykład „pstack”) w celu wyjścia ślad stosu swojego rozbitego zadania. Kiedy exec -ing (po fork -ing, w potomstwie), musisz przekazać swój identyfikator procesu za pomocą getppid; i w rodzicu musisz wait, aby go zakończyć, zanim zadzwonisz pod numer abort.

Z drugiej strony, jeśli starasz się zrobić „czysty” zjazd po SIGSEGV (np zagwarantowanie C++ destruktory się nazywa, itp) - wtedy należy ostrzec, że POSIX mówi:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_02:

zachowanie procesu jest niezdefiniowana po zignorowaniu SIGFPE, SIGILL SIGSEGV lub sygnał SIGBUS które nie zostały wygenerowane przez kill(), sigqueue() lub podnieść().

i http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03:

Zachowanie procesu jest zdefiniowana po zwraca zwykle od funkcję sygnału uwagę na SIGBUS, SIGFPE, SIGILL lub SIGSEGV nie został wygenerowany przez kill(), sigqueue() lub raise().