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. Advertisements

  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. Advertisements

  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. Advertisements

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. Frank Bossy
    Replies:
    1
    Views:
    581
    Victor Bazarov
    Jul 9, 2003
  2. Gabriele Bartolini

    Signals, threads and the use of SIGUSR1

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

    Signals and threads again

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

    Threads and signals

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

    Signals and threads

    shibu-kundara, Nov 24, 2006, in forum: C Programming
    Replies:
    2
    Views:
    399
    Mark McIntyre
    Nov 24, 2006
  7. geoffbache
    Replies:
    6
    Views:
    623
    fumanchu
    Jun 11, 2007
  8. Ara.T.Howard

    signals handlers and threads

    Ara.T.Howard, Sep 21, 2005, in forum: Ruby
    Replies:
    3
    Views:
    198
    Rick Nooner
    Sep 21, 2005
Loading...