From: Eric Schwartz <eric.schwartz@...>
Date: 2004-09-01T08:14:30+09:00
Subject: Re: Ruby is eating my signals!

On Tue, 2004-08-31 at 13:05, Berger, Daniel wrote:
> Well, one thing I'm curious about is why you need to setup a separate
> ALRM handler in addition to a timeout.  I would think wrapping your STAF
> query in a timeout, and catching a TimeoutError, would be sufficient.
> Please correct me if I'm wrong.

I hav tried the TimoutError approach; the problem is that the
TimeoutError never actually gets to my code, probably for the same
reason the SIGALRM handler never does.  

What's happening is that the STAF library does a connect() to the remote
system, and that connect() is what is hanging.  When Ruby recieves the
SIGALRM, rb_trap_immediate is not set, so the signal is deferred-- the
problem is, because it's hanging inside the connect(), the Ruby
internals that poll that deferred list never get called, so the signal
is effectively "eaten".

> Also, I don't see anything in your source to indicate that you've tried
> to trap the ALRM signal anywhere.  Do you have a code snippet you could
> share?  That would help.  I'm afraid I don't use STAF so I can't really
> test.

Sure:
  parent = $$
  timeout = fork do
    sleep 5
    Process.kill "ALRM", parent
  end
  begin
    cmd = STAF::STAFCommand.new(machine, STAF::PROCESS_SVC,
				"query handle #{handle}")
  rescue SignalException => se
    return false
  end
  # this prevents it from firing off after we exit.
  Process.kill -9 timeout  

> Lastly, as a sanity check, create a simple alarm handler and make sure
> it works properly on your platform (which I'm guessing is Linux, but I
> don't remember for sure):

Yes, I'm on Linux (x86).  An ordinary alarm handler works fine.

> Then try adding in timeout code similar to what you're doing with STAF.

I have done; that all works fine.

> Now, if *that* doesn't work, then there may be a bug in Ruby, or perhaps
> there's a Linux specific issue.

Hence my query. :)

-=Eric
-- 
Eric Schwartz <eric.schwartz@hp.com>
Hewlett-Packard Company Linux/Open Source Labs (LOSL)