Error with Signals and Threads in Ruby 2.0

[asenchi]

Ran into this today, which is the result of Ruby 2.0 changes.

/data/github/current/vendor/gems/2.1.0/ruby/2.1.0/gems/scrolls-0.3.5/lib/scrolls/atomic.rb:22:in `synchronize': can't be called from trap context (ThreadError)
    from /data/github/current/vendor/gems/2.1.0/ruby/2.1.0/gems/scrolls-0.3.5/lib/scrolls/atomic.rb:22:in `get'
    from /data/github/current/vendor/gems/2.1.0/ruby/2.1.0/gems/scrolls-0.3.5/lib/scrolls/atomic.rb:46:in `value'
    from /data/github/current/vendor/gems/2.1.0/ruby/2.1.0/gems/scrolls-0.3.5/lib/scrolls/log.rb:176:in `get_global_context'
    from /data/github/current/vendor/gems/2.1.0/ruby/2.1.0/gems/scrolls-0.3.5/lib/scrolls/log.rb:96:in `log'
    from /data/github/current/vendor/gems/2.1.0/ruby/2.1.0/gems/scrolls-0.3.5/lib/scrolls.rb:54:in `log'
...

[asenchi]

Interesting discussion about using Queue (now thread-safe). Considering a queue for AtomicObject, but not sure yet. I've never felt dumber than this moment. LOL

[asenchi]

Considering implementing a CAS (compare and swap) in Scrolls to solve this issue. Going to hack on that for a bit.

[asenchi]

After talking with @lindvall it's apparent that we can't solve this problem at this level. Not sure yet what to do, yet, when it comes to the global_context.

[asenchi]

LOL, sorry that was supposed to be @eric. Usernames are hard.

[asenchi]

I posted this on an internal issue, but here is some more information:

So it looks like this is hitting the new trap/thread handling in Ruby 2.0. Some references:

• https://bugs.ruby-lang.org/issues/7917
• https://bugs.ruby-lang.org/issues/8823

All boils down to this code in Scrolls. Trying to work through an elegant way of handling this.

[asenchi]

Should no longer be an issue after #71