Signals and threads

Discussion in 'Ruby' started by Gennady, Jun 9, 2004.

  1. Gennady

    Gennady Guest

    Hi, there

    If I have several threads and set a signal handler proc with
    Kernel::trap, what thread will actually execute the handler? Is it
    always guaranteed to be the main thread as I see it now?

    Thank you,
    Gennady.
     
    Gennady, Jun 9, 2004
    #1
    1. Advertising

  2. Gennady

    Guest

    Hi,

    At Thu, 10 Jun 2004 04:22:41 +0900,
    Gennady wrote in [ruby-talk:102985]:
    > If I have several threads and set a signal handler proc with
    > Kernel::trap, what thread will actually execute the handler? Is it
    > always guaranteed to be the main thread as I see it now?


    Yes, it's a feature.

    --
    Nobu Nakada
     
    , Jun 10, 2004
    #2
    1. Advertising

  3. On Jun 9, 2004, at 6:52 PM, wrote:

    > Hi,
    >
    > At Thu, 10 Jun 2004 04:22:41 +0900,
    > Gennady wrote in [ruby-talk:102985]:
    >> If I have several threads and set a signal handler proc with
    >> Kernel::trap, what thread will actually execute the handler? Is it
    >> always guaranteed to be the main thread as I see it now?

    >
    > Yes, it's a feature.


    Thank you very much, Nobu. By the way, I was trying to temporarily set
    a signal handler with trap:

    sigquit_handler = trap "SIGQUIT", "IGNORE"
    ... <the code spawning a process (with popen) where I want SIGQUIT
    ignored>
    trap "SIGQUIT", sigquit_handler

    I noticed that when the first trap returns nil, the second one does not
    restore a signal handler to "DEFAULT", as I would expect. I have to do
    something like that:

    trap "SIGQUIT", (sigquit_handler or "DEFAULT")

    Thanks again,
    Gennady.

    >
    > --
    > Nobu Nakada
    >
    >


    Sincerely,
    Gennady Bystritsky
     
    Gennady Bystritsky, Jun 10, 2004
    #3
  4. Gennady

    Guest

    Hi,

    At Thu, 10 Jun 2004 16:37:02 +0900,
    Gennady Bystritsky wrote in [ruby-talk:103056]:
    > sigquit_handler = trap "SIGQUIT", "IGNORE"
    > ... <the code spawning a process (with popen) where I want SIGQUIT
    > ignored>
    > trap "SIGQUIT", sigquit_handler
    >
    > I noticed that when the first trap returns nil, the second one does not
    > restore a signal handler to "DEFAULT", as I would expect. I have to do
    > something like that:
    >
    > trap "SIGQUIT", (sigquit_handler or "DEFAULT")


    Which version of ruby do you use? It should return nil at the
    first.

    $ ruby18 -v -e 'p trap("SIGQUIT", nil)'
    ruby 1.8.2 (2004-06-06) [i686-linux]
    "DEFAULT"

    --
    Nobu Nakada
     
    , Jun 10, 2004
    #4
  5. Gennady

    Gennady Guest

    wrote:
    > Hi,
    >
    > At Thu, 10 Jun 2004 16:37:02 +0900,
    > Gennady Bystritsky wrote in [ruby-talk:103056]:
    >
    >>sigquit_handler = trap "SIGQUIT", "IGNORE"
    >>... <the code spawning a process (with popen) where I want SIGQUIT
    >>ignored>
    >>trap "SIGQUIT", sigquit_handler
    >>
    >>I noticed that when the first trap returns nil, the second one does not
    >>restore a signal handler to "DEFAULT", as I would expect. I have to do
    >>something like that:
    >>
    >>trap "SIGQUIT", (sigquit_handler or "DEFAULT")

    >
    >
    > Which version of ruby do you use? It should return nil at the
    > first.
    >
    > $ ruby18 -v -e 'p trap("SIGQUIT", nil)'
    > ruby 1.8.2 (2004-06-06) [i686-linux]
    > "DEFAULT"
    >

    I use 1.6.8, and there trap returns nil if no handler is currently in
    use. I checked in 1.8.0 and it returns "DEFAULT", just as you mentioned.
    Thanks a lot. I will be gradually switching to 1.8.x.

    Gennady.

    [linux.gfbs:274]gfb> ruby -v -e 'p trap("SIGQUIT", "IGNORE")'
    ruby 1.6.8 (2003-10-15) [i686-linux]
    nil
    [linux.gfbs:275]gfb> ruby8 -v -e 'p trap("SIGQUIT", "IGNORE")'
    ruby 1.8.0 (2003-08-04) [i686-linux]
    "DEFAULT"
     
    Gennady, Jun 10, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gabriele Bartolini

    Signals, threads and the use of SIGUSR1

    Gabriele Bartolini, Oct 3, 2003, in forum: C++
    Replies:
    4
    Views:
    1,532
    Peter Zijlstra
    Oct 11, 2003
  2. Srikanth Mandava
    Replies:
    1
    Views:
    396
    Michael Hudson
    Feb 19, 2004
  3. Mitko Haralanov

    Signals and threads again

    Mitko Haralanov, Oct 13, 2006, in forum: Python
    Replies:
    0
    Views:
    264
    Mitko Haralanov
    Oct 13, 2006
  4. Chad J. Schroeder

    Threads and signals

    Chad J. Schroeder, Nov 15, 2006, in forum: Python
    Replies:
    1
    Views:
    336
    Chad J. Schroeder
    Nov 16, 2006
  5. shibu-kundara

    Signals and threads

    shibu-kundara, Nov 24, 2006, in forum: C Programming
    Replies:
    2
    Views:
    322
    Mark McIntyre
    Nov 24, 2006
Loading...

Share This Page