lkml.org 
[lkml]   [1999]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: signal semantics are a pain in the arse
    From
    Date
    Alan Donovan <adonovan@imerge.co.uk> writes:
    >
    > Having come back to Linux and having just read W.R.Stevens "Advanced
    > Programming in the UNIX Environment" it strikes me that the whole signal
    > thing is a right mess. In a signal handler you have no context as to the
    > cause of the signal, there's almost nothing you can actually do in the
    > handler because of reentrancy problems, and you have to remember to
    > restart system calls everywhere (or does Linux do BSD-style
    > auto-restarting?).

    It does. Just set SA_RESTART in sigaction. glibc even defaults to this
    for signal(2), but you should not use that anyways.

    Modern signals also support telling you about the context and their cause
    and even some payload (via siginfo_t/SA_SIGINFO), unfortunately this so far
    only works for queued realtime signals in Linux.

    You can e.g. use it by setting a realtime signal (>SIGRTMIN) to a file
    descriptor for SIGIO using fcntl(fd,F_SETSIG,sig), and then receive
    the fd that caused the SIGIO and even the cause in siginfo->si_band/si_fd.

    Even "old" signals can tell you something about their context if you don't
    mind CPU specific code via sigcontext_struct.


    -Andi

    --
    This is like TV. I don't like TV.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.021 / U:1.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site