sigwait(&ss, SIGCONT) - Unix

This is a discussion on sigwait(&ss, SIGCONT) - Unix ; can i sigwait() for SIGCONT? i don't seem to be able to. i would expect that i can, since a handler can be set for it. -frank...

+ Reply to Thread
Results 1 to 9 of 9

Thread: sigwait(&ss, SIGCONT)

  1. sigwait(&ss, SIGCONT)

    can i sigwait() for SIGCONT? i don't seem to be able to. i would
    expect that i can, since a handler can be set for it.

    -frank

  2. Re: sigwait(&ss, SIGCONT)

    On Fri, 01 Feb 2008 01:09:25 -0800, Frank Cusack
    wrote:

    >can i sigwait() for SIGCONT? i don't seem to be able to. i would
    >expect that i can, since a handler can be set for it.


    The default disposition for SIGCONT is "ignore", so I suppose that you
    shouldn't be able to sigwait() for it.

    Cheers,

    Michael

  3. Re: sigwait(&ss, SIGCONT)

    On Tue, 05 Feb 2008 00:43:12 +0100 Michael Kerrisk wrote:
    > On Fri, 01 Feb 2008 01:09:25 -0800, Frank Cusack
    > wrote:
    >
    >>can i sigwait() for SIGCONT? i don't seem to be able to. i would
    >>expect that i can, since a handler can be set for it.

    >
    > The default disposition for SIGCONT is "ignore", so I suppose that you
    > shouldn't be able to sigwait() for it.


    ignored or not has no bearing, at least it shouldn't. you can sigwait()
    for SIGCHLD, whose default disposition is also "ignore".

    -frank

  4. Re: sigwait(&ss, SIGCONT)

    On Feb 4, 5:54 pm, Frank Cusack wrote:
    > On Tue, 05 Feb 2008 00:43:12 +0100 Michael Kerrisk wrote:
    > > On Fri, 01 Feb 2008 01:09:25 -0800, Frank Cusack wrote:

    >
    >>> can i sigwait() for SIGCONT? i don't seem to be able to. i
    >>> would expect that i can, since a handler can be set for it.

    >
    >> The default disposition for SIGCONT is "ignore", so I suppose
    >> that you shouldn't be able to sigwait() for it.

    >
    > ignored or not has no bearing, at least it shouldn't. you can
    > sigwait() for SIGCHLD, whose default disposition is also "ignore".


    Yeah, sounds like a defect in whatever platform you're doing this on,
    or at least on any that claims to comply with SUSv3, which says:
    If the action associated with a blocked signal is anything
    other than to ignore the signal, and if that signal is
    generated for the thread, the signal shall remain pending
    until it is unblocked, it is accepted when it is selected and
    returned by a call to the sigwait() function, or the action
    associated with it is set to ignore the signal.

    So, is the action associated with SIGCONT "to ignore the signal" when
    it has its default disposition? Later we read:

    The actions prescribed by these values are as follows:
    SIG_DFL
    Signal-specific default action.
    ....
    Setting a signal action to SIG_DFL for a signal that is
    pending, and whose default action is to ignore the signal
    (for example, SIGCHLD), shall cause the pending signal to
    be discarded, whether or not it is blocked.
    ....
    The default action for SIGCONT is to resume execution at
    the point where the process was stopped, after first handling
    any pending unblocked signals.

    Furthermore, the table of signals in the signal.h description does
    _not_ show SIGCONT as having a default action of "I" for ignore.

    So, it sure looks to me like SIGCONT *should* be available to
    sigwait() when it has its default disposition.


    That said, the workaround is trivial: use sigaction() to set a do-
    nothing signal handler for SIGCONT before you call sigwait(). Solaris
    8-10 exhibit the behavior you describe, but calling sigaction() first
    lets my test program catch the SIGCONT with sigwait().


    Philip Guenther

  5. Re: sigwait(&ss, SIGCONT)

    On Feb 1, 4:09 am, Frank Cusack wrote:
    > can i sigwait() for SIGCONT? i don't seem to be able to. i would
    > expect that i can, since a handler can be set for it.
    >
    > -frank


    SIGCONT is special - as you know it is used in conjunction with
    SIGSTOP for resuming/handling a process.
    I have yet to retrieve the POSIX doc for what I'm about to write.
    SIGCONT *cannot* be blocked (some thing that sigwait() expect) but can
    be caught and have a signal handler associated with it. It cannot be
    blocked, otherwise you would not be able to continue a stopped
    process, which is something you do not want to happen ;-)
    As posted by Philip Guenther, a dummy signal handler will make
    sigaction do what you want to do - that's the only way for the kernel
    (Solaris handles it the right way) to make sigwait() workable for you
    - otherwise its job is to make SIGCONT unnoticed (it forces the kernel
    to deliver the signal and deliver an EINTR).

    my 2 cents: you should not mess with this guy ;-) since it cannot a
    bunch of POSIX signal APIs will be racy :-(

    what is the rational for waiting for SIGCONT ?

  6. Re: sigwait(&ss, SIGCONT)

    ppi writes:
    > On Feb 1, 4:09 am, Frank Cusack wrote:
    >> can i sigwait() for SIGCONT? i don't seem to be able to. i would
    >> expect that i can, since a handler can be set for it.
    >>
    >> -frank

    >
    > SIGCONT is special - as you know it is used in conjunction with
    > SIGSTOP for resuming/handling a process.
    > I have yet to retrieve the POSIX doc for what I'm about to write.
    > SIGCONT *cannot* be blocked


    This isn't strictly true:

    When SIGCONT is generated for a process that is stopped, the
    process shall be continued, even if the SIGCONT signal is
    blocked or ignored. If SIGCONT is blocked and not ignored, it
    shall remain pending until it is either unblocked or a stop
    signal is generated for the process.
    (SUS 2.4.1/ Signal Generation and Delivery)


  7. Re: sigwait(&ss, SIGCONT)

    > This isn't strictly true:
    >
    > When SIGCONT is generated for a process that is stopped, the
    > process shall be continued, even if the SIGCONT signal is
    > blocked or ignored. If SIGCONT is blocked and not ignored, it
    > shall remain pending until it is either unblocked or a stop
    > signal is generated for the process.
    > (SUS 2.4.1/ Signal Generation and Delivery)


    That's what you get for not check the SUS ;-)
    Thanks for the correction.

  8. Re: sigwait(&ss, SIGCONT)

    On Mon, 4 Feb 2008 20:38:40 -0800 (PST) "guenther@gmail.com" wrote:
    > Furthermore, the table of signals in the signal.h description does
    > _not_ show SIGCONT as having a default action of "I" for ignore.


    ah, but on my platform (Solaris 10), the man page for signal.h does
    in fact show the default action to be ignore. Furthermore, while
    the chart in SUSv3 shows "C", the description for "C" is to

    Continue the process, if it is stopped; otherwise, ignore the signal.

    So it seems correct that I cannot wait for it until I set a handler.

    I wonder what is supposed to happen if I am waiting for it, and then
    my process is stopped. Since the action is now "anything other than
    to ignore the signal", shouldn't sigwait() receive the signal? Seems
    like a defect in SUSv3.

    thanks
    -frank

  9. Re: sigwait(&ss, SIGCONT)

    On Tue, 5 Feb 2008 06:21:43 -0800 (PST) ppi wrote:
    > what is the rational for waiting for SIGCONT ?


    I wanted to use it as a signalling mechanism between threads. Since
    SIGCONT is otherwise innocuous, I thought it might be a good signal.

    That thought (using signals) lasted about 30s before I decided it was
    a bad idea, and I went with a semaphore instead. But I found the
    SIGCONT behavior odd so I thought I'd post the question anyway.

    -frank

+ Reply to Thread