I get the same error as Gerenje on a RedHat Enterprise 5.1 with the same code.

I have the same problem as Gerenje and Ahsan, but I’m on SuSE Linux Enterprise Server 10, 64-bit.

Hm, I've just installed the gem and found an interesting (if irritating) feature:

Thread.new do
  SystemTimer.timeout(30) do
     doing_something_that_takes_more_than_30s
  end
end

This works fine, nothing happens and the do something is killed. However when I do something that takes less than 30 seconds and completes, I get:

cleanup_timer: Previous SIG_ALRM handler not initialized!:

Example:

bash> irb
irb(main):001:0> require 'system_timer'
=> true
irb(main):002:0> (1..4).each do
irb(main):003:1*     Thread.new do
irb(main):004:2*       SystemTimer.timeout(5) do
irb(main):005:3*         puts "hi there!" 
irb(main):006:3>       end
irb(main):007:2>     end
irb(main):008:1>   end
hi there!hi there!hi there!
hi there!
cleanup_timer: Previous SIG_ALRM handler not initialized!: 
=> 1..4
irb(main):009:0> 
cleanup_timer: Previous SIG_ALRM handler not initialized!:

cleanuptimer: Previous SIGALRM handler not initialized!: Alarm clock bash>

Worse still, my irb gets shot in the head (Alarm clock) and I'm back in bash.

Also using this in production causes all threads to exit immediately with the "SIG_ALRM" error, i.e. the code block doesn't actually start execution.

BTW I did this all on a MacBook, ie BSD system—> it should work with BSD right?

Hi guys,

These are really great news, but it made me think about how many features are really broken in Ruby implementation.

I am experiencing problems with net/imap.rb, and realized that there's yet another "homicidal thread"-based timeout implementation in
lib/ruby/1.8/monitor.rb:

def create_timer(timeout)
  if timeout
    waiter = Thread.current
    return Thread.start {
      Thread.pass
      sleep(timeout)
      Thread.critical = true
      waiter.raise(Timeout.new)
    }
  else
    return nil
  end
end

I guess it would it be possible to monkey-patch this and solve the problem safely using SystemTimer, but I am not sure. I'll have a try anyway.

Thanks for the great work!

Cheers.

Elderclei Reami

@Elderclei Reami: It's not really that the Ruby implementation is broken. It's just the nature of userspace threads. I also kinda blame it on operating systems for not providing non-blocking/asynchronous APIs for everything. Current operating system APIs kinda force you to use kernel threads. And that's a pity, because userspace threads are much more lightweight than kernel threads, and when used properly they can bring many performance benefits.

I get your point Hongli, and green threads are something really useful, as shown by Erlang.

What I was trying to mention is that there is duplicated timeout code spread everywhere, even though they seem to be the same (copy & paste?). By the way, we are using SystemTimer in production and it's working quite well – thank you, Philippe.

Cheers,

PS: Thanks for your amazing packages (REE and Phusion)

Thanks for a wonderful gem, I am wondering if the exception is guaranteed within the given time? because when i tried

require "open-uri"
SystemTimer.timeout_after(1) do
  open("http://www.abcd.comz")
end

The exception is raised, but after 15-20 seconds instead of 1 second. I am running ubuntu 6.10 and ruby 1.8.6

THANK YOU FOR THIS!

I have been fighting with a timeout problem where a certain process was doing a call to another DB on the other side of the planet and it kept timing out, but timeout.rb would never die and the process would just sit there and lock.

Of course, the cron job would not fire again because an existing process was running. Was about to resort to system level monitoring apps to try and fix it. This came as a timely save.

Thanks again.

Mikel

I have a fix for the reported issues. I have sent a patch to the author, but if you need it immediately, please contact me by email. First initial last name at nexopia dot com.

Thanks for the excellent gem! Good work.

As an aside, the JRuby interpreter does not use green threads, and instead delegates all threading to the underlying JVM (implementation varies by platform, but is never "green"; but pretty robust). This should solve much of the problem, but not all of it, since I have seen Java threads hang on some system calls as well (especially network calls under Linux). I have not had a chance to test it with a recent JVM and in particular did not test the JRuby implementation. Since JRuby performance is now on a par with the rest of the leading Ruby interpreters, it is now a viable candidate for use as a primary deployment platform.

I wonder whether anyone tested these issues with a recent JRuby interpreter

Thanks ahead or any responses

Hi,

SystemTimer-1.1.3 fail to install on ubuntu with Ruby 1.9.1. I try to look at some fix. Already reported here : http://isitruby19.com/systemtimer

sudo gem install SystemTimer
Building native extensions.  This could take a while...
ERROR:  Error installing SystemTimer:
    ERROR: Failed to build gem native extension.

/usr/bin/ruby1.9.1 extconf.rb
creating Makefile

make
cc -I. -I/usr/include/ruby-1.9.1/x86_64-linux -I/usr/include/ruby-1.9.1/ruby/backward -I/usr/include/ruby-1.9.1 -I.   -fPIC -fno-strict-aliasing -g -g -O2 -O2 -g -Wall -Wno-parentheses  -fPIC  -o system_timer_native.o -c system_timer_native.c
In file included from system_timer_native.c:8:
/usr/include/ruby-1.9.1/ruby/backward/rubysig.h:14:2: warning: #warning rubysig.h is obsolete
system_timer_native.c: In function ‘restore_original_configuration’:
system_timer_native.c:166: warning: no return statement in function returning non-void
system_timer_native.c: In function ‘install_ruby_sigalrm_handler’:
system_timer_native.c:199: error: ‘rb_thread_critical’ undeclared (first use in this function)
system_timer_native.c:199: error: (Each undeclared identifier is reported only once
system_timer_native.c:199: error: for each function it appears in.)
system_timer_native.c: In function ‘restore_original_ruby_sigalrm_handler’:
system_timer_native.c:205: error: ‘rb_thread_critical’ undeclared (first use in this function)
make: *** [system_timer_native.o] Error 1


Gem files will remain installed in /var/lib/gems/1.9.1/gems/SystemTimer-1.1.3 for inspection.
Results logged to /var/lib/gems/1.9.1/gems/SystemTimer-1.1.3/ext/system_timer/gem_make.out

Hi Phillippe,

Great work on the gem! I could use some help though -- we are trying to wrap a Ruby/LDAP search with SystemTimer, to timeout after 5.seconds. It does timeouts, but doesn't long after the 5 seconds have passed:

require 'ldap' require 'system_timer'

arr = SystemTimer::timeout_after(5.seconds) do
    connection.search2(self.base_dn,1,"(& (userPassword=#{password}) (mail=#{email}))",nil,false,0,0)
  end

If the LDAP query string is wrong for some reason, the LDAP server connection hangs (that's the server fault, of course, and that's why I wanted to use SystemTimer) for more than 1 minute. Then, it raises the Timeout exception.

I'm using SystemTimer v. 1.2.

Any ideas why it is failing?

Cheers,

Marcelo.

Hi Phillippe,

I tried to install in windows with ruby 1.86 , error occured below

gem install systemtimer

gem install system_timer

And got error:

'make' is not recognized as an internal or external command operable program or batch file.

I need this for my dev env. is there is anyway to install to windows?

thank you , jisub,lee from south korea