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 Please
look at the gist:

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:

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

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.


require “gserver”

example server

class MyServer < GServer
def initialize(port=10001, *args)
super(port, *args)
def serve(io)

class Launcher
def initialize(servers)
@servers = servers

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

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

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

servers = []
launcher =

create self-pipe

p_read, p_write = IO.pipe

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

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

Wow, this is a really interesting (and effective) solution. Reading the
docs on IO.pipe ( 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: It hasn’t gained any traction
but if you want to post your own experience with Queue#enq it might be
addendum to this bug report or a new bug altogether.

Thanks for your help! This was educational.


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