[#115244] [Ruby master Feature#19987] add sample method to Range — "horv77@... (Andras Horvath) via ruby-core" <ruby-core@...>
Issue #19987 has been reported by horv77@protonmail.com (Andras Horvath).
6 messages
2023/11/05
[#115247] [Ruby master Feature#19988] AI for inner code behavior analysis at runtime — "horv77@... (Andras Horvath) via ruby-core" <ruby-core@...>
Issue #19988 has been reported by horv77@protonmail.com (Andras Horvath).
3 messages
2023/11/05
[#115404] Ruby 3.2.2 - rbconfig.rb's MAKEFILE_CONFIG — Jay Mav via ruby-core <ruby-core@...>
Hello Ruby Dev Team,
4 messages
2023/11/17
[ruby-core:115225] [Ruby master Feature#16476] Socket.getaddrinfo cannot be interrupted by Timeout.timeout
From:
"mame (Yusuke Endoh) via ruby-core" <ruby-core@...>
Date:
2023-11-02 08:07:37 UTC
List:
ruby-core #115225
Issue #16476 has been updated by mame (Yusuke Endoh).
Status changed from Open to Closed
#19965 solved the problem, so I'll close it.
I completely forgot this ticket, but the concept (pthread_create on every call to getaddrinfo(3)) was the same as in #19965. Just for case, #19965 is a bit more elaborate:
* It works as before in environments where pthread is not available.
* It includes the same hack for not only `getaddrinfo(3)` but also `getnameinfo(3)`.
* `pthread_cancel` is not used because until recently [there was a bug in glibc](https://bugzilla.redhat.com/show_bug.cgi?id=1405071) where `pthread_cancel` of a pthread that is calling `getaddrinfo(3)` would cause subsequent name resolution to stick:
* It attempts to use `pthread_setaffinity_np` to reduce speed degradation.
----------------------------------------
Feature #16476: Socket.getaddrinfo cannot be interrupted by Timeout.timeout
https://bugs.ruby-lang.org/issues/16476#change-105143
* Author: kirs (Kir Shatrov)
* Status: Closed
* Priority: Normal
* Assignee: Glass_saga (Masaki Matsushita)
----------------------------------------
It seems like the blocking syscall done by `Socket.getaddrinfo` blocks Ruby VM in a way that Timeout.timeout has no effect.
See reproduction steps in getaddrinfo_interrupt.rb (https://gist.github.com/kirs/00c02ef92e0418578135fe0a6cbd3d7d). This affects all modern Ruby versions, including the latest 2.7.0.
Combined with default 10s resolv timeout on many Linux systems, this can have a very noticeable effect on production Ruby apps being not resilient to slow DNS resolutions, and being unable to fail fast even with `Timeout.timeout`.
While https://bugs.ruby-lang.org/issues/15553 improves the situation for `Addrinfo.getaddrinfo`, `Socket.getaddrinfo` is still blocking the VM and Timeout has no effect.
I'd like to discuss what could be done to make that call non-blocking for threads in Ruby VM.
**UPD:** looking closer, I can see that `Socket.getaddrinfo("www.ruby-lang.org", "http")` and `Addrinfo.getaddrinfo("www.ruby-lang.org", "http")` call non-interruptible `getaddrinfo`, while `Addrinfo.getaddrinfo("www.ruby-lang.org", "http", timeout: 10)` calls `getaddrinfo_a`, which is interruptible:
``` ruby
# interrupts as expected
Timeout.timeout(1) do
Addrinfo.getaddrinfo("www.ruby-lang.org", "http", timeout: 10)
end
```
I'd maybe suggest that we try to *always* use `getaddrinfo_a` when it's available, including in `Socket.getaddrinfo`. What downsides that would have?
I'd be happy to work on a patch.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/