GServer in Ruby 2.0.0

I’m working on updating a gem to be compatible with Ruby 2.0 and am
currently using Ruby 2.0.0-preview2. I’m running into trouble with a
class which inherits from GServer and I think it’s related to this bug
and subsequent patch https://bugs.ruby-lang.org/issues/6416. Please
look at the gist:https://gist.github.com/4424479

Using Ruby <= 1.9.3, when sending an interrupt signal this code would
exit cleanly. Using Ruby 2.0, an exception is thrown on launcher.stop:

~/.rvm/rubies/ruby-2.0.0-preview2/lib/ruby/2.0.0/gserver.rb:116:in
synchronize': can't be called from trap context (ThreadError) from ~/.rvm/rubies/ruby-2.0.0-preview2/lib/ruby/2.0.0/gserver.rb:116:instop’

As you can see, I am not explicitly calling ‘join’ in the trap context
but ‘synchronize’ is called as part of GServer#close

gserver.rb
114 # Stop the server
115 def stop
116 @connectionsMutex.synchronize {
117 if @tcpServerThread
118 @tcpServerThread.raise “stop”
119 end
120 }
121 end

I’m open to any ideas or suggestions. Thanks!

On Tue, Jan 1, 2013 at 4:20 PM, Joe L. [email protected] wrote:

synchronize': can't be called from trap context (ThreadError) from ~/.rvm/rubies/ruby-2.0.0-preview2/lib/ruby/2.0.0/gserver.rb:116:instop’

I can confirm this is new behaviour in 2.0.0-preview2 - it also
happens when you use Queue#enq from within a trap handler (which is an
issue for me unfortunately).

You could use a variant of the self-pipe trick to signal a thread as
in the example below. Regards, Sean.

CODE

require “gserver”

example server

class MyServer < GServer
def initialize(port=10001, *args)
super(port, *args)
end
def serve(io)
io.puts(Time.now.to_s)
end
end

class Launcher
def initialize(servers)
@servers = servers
end

def start
@servers.each { |server| server.start }
end

def join
@servers.each { |server| server.join }
end

def stop
@servers.each { |server| server.stop }
end
end

servers = [MyServer.new]
launcher = Launcher.new(servers)

create self-pipe

p_read, p_write = IO.pipe

Thread.start(launcher, p_read) do |l, pr|
pr.read # blocks until write end closed
pr.close
l.stop
exit
end

launcher.start
trap(“SIGINT”) { p_write.close } # close pipe to signal thread
launcher.join

Wow, this is a really interesting (and effective) solution. Reading the
docs on IO.pipe (http://www.ruby-doc.org/core-1.9.3/IO.html) this looks
pretty safe. And it works on Ruby 1.9.3 and 2.0.0-preview2.

My objective was to clean up my resources when the program receives a
SIGTERM. (As a counter example, calling “exit!” inside the original trap
context in my gist would have successfully killed my program without
throwing an exception but would not have cleaned up the utilized
resources.) There is the ominous “does not work on all systems” warning
with this method, but if I can test it out on some of the major ones
successfully, I’ll go with it.

For what it’s worth, I’ve filed my issue with ruby-core here:
http://bugs.ruby-lang.org/issues/7648. It hasn’t gained any traction
yet,
but if you want to post your own experience with Queue#enq it might be
an
addendum to this bug report or a new bug altogether.

Thanks for your help! This was educational.

Joe

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs