[#75687] [Ruby trunk Bug#12416] struct rb_id_table lacks mark function — shyouhei@...
Issue #12416 has been reported by Shyouhei Urabe.
3 messages
2016/05/23
[#75763] [Ruby trunk Feature#12435] Using connect_nonblock to open TCP connections in Net::HTTP#connect — mohamed.m.m.hafez@...
Issue #12435 has been reported by Mohamed Hafez.
3 messages
2016/05/28
[#75774] Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock — Mohamed Hafez <mohamed.m.m.hafez@...>
Hi all, every now and then in my production server, I'm
4 messages
2016/05/30
[#75775] Re: Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock
— Mohamed Hafez <mohamed.m.m.hafez@...>
2016/05/30
Or does MRI's OpenSSL::SSL::SSLSocket#connect_nonblock just return
[#75782] Important: Somewhat backwards-incompatible change (Fwd: [ruby-cvs:62388] duerst:r55225 (trunk): * string.c: Activate full Unicode case mapping for UTF-8) — Martin J. Dürst <duerst@...>
With the change below, I have activated full Unicode case mapping for
4 messages
2016/05/31
[ruby-core:75636] [Ruby trunk Bug#12405] Queue doesn't work inside of trap
From:
kirillrdy@...
Date:
2016-05-20 06:13:12 UTC
List:
ruby-core #75636
Issue #12405 has been reported by Kirill Radzikhovskyy.
----------------------------------------
Bug #12405: Queue doesn't work inside of trap
https://bugs.ruby-lang.org/issues/12405
* Author: Kirill Radzikhovskyy
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v: ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
when adding things to the queue inside that trap blocking pop never unblocks
~~~
q = Queue.new
Signal.trap 'INT' do
puts "got INT"
q << 'something'
end
Thread.new {
loop {
sleep 1
Process.kill :INT, $$
}
}
q.pop
~~~
I know that there are limitations of what can be done inside of trap.
Looking at this https://bugs.ruby-lang.org/issues/6128 it looks like I should be able to use Queue inside a trap, but code above runs forever.
Also in jruby it behaives as expected ( at least in my understanding )
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>