[#114936] [Ruby master Feature#19908] Update to Unicode 15.1 — "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>

Issue #19908 has been reported by nobu (Nobuyoshi Nakada).

24 messages 2023/10/02

[#115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19921 has been reported by vo.x (Vit Ondruch).

21 messages 2023/10/12

[#115033] [Ruby master Misc#19925] DevMeeting-2023-11-07 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19925 has been reported by mame (Yusuke Endoh).

12 messages 2023/10/13

[#115068] [Ruby master Bug#19929] Warnings for `mutex_m`, `drb` and `base64` appears while the gem spec has explicit dependencies — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

Issue #19929 has been reported by yahonda (Yasuo Honda).

8 messages 2023/10/17

[#115071] [Ruby master Misc#19931] to_int is not for implicit conversion? — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19931 has been reported by Dan0042 (Daniel DeLorme).

16 messages 2023/10/17

[#115139] [Ruby master Bug#19969] Regression of memory usage with Ruby 3.1 — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>

Issue #19969 has been reported by hsbt (Hiroshi SHIBATA).

8 messages 2023/10/24

[#115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19972 has been reported by vo.x (Vit Ondruch).

11 messages 2023/10/25

[#115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil` — "ufuk (Ufuk Kayserilioglu) via ruby-core" <ruby-core@...>

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu).

21 messages 2023/10/29

[ruby-core:115104] [Ruby master Feature#19965] Make the name resolution interruptible

From: "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>
Date: 2023-10-19 03:34:03 UTC
List: ruby-core #115104
Issue #19965 has been reported by mame (Yusuke Endoh).

----------------------------------------
Feature #19965: Make the name resolution interruptible
https://bugs.ruby-lang.org/issues/19965

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
## Problem

Currently, Ruby name resolution is not interruptible.

```
$ cat /etc/resolv.conf
nameserver 198.51.100.1

$ ./local/bin/ruby -rsocket -e 'Addrinfo.getaddrinfo("www.ruby-lang.org", 80)'
^C^C^C^C
```

If you set a non-responsive IP as the nameserver, you cannot stop `Addrinfo.getaddrinfo` by pressing Ctrl+C. Note that `Timeout.timeout` does not work either.

This is because there is no way to cancel `getaddrinfo(3)`.

## Proposal

I wrote a patch to make `getaddrinfo(3)` work in a separate pthread.

https://github.com/ruby/ruby/pull/8695

Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it.
The caller thread waits for the worker to complete.
When an interrupt occurs, the caller thread leaves stop waiting and leaves the worker pthread.
The detached worker pthread will exit after `getaddrinfo(3)` completes (or name resolution times out).

## Evaluation

By applying this patch, name resolution is now interruptible.

```
$ ./local/bin/ruby -rsocket -e 'pp Addrinfo.getaddrinfo("www.ruby-lang.org", 80)'
^C-e:1:in `getaddrinfo': Interrupt
        from -e:1:in `<main>'
```

As a drawback, name resolution performance will be degraded.

```
10000.times { Addrinfo.getaddrinfo("www.ruby-lang.org", 80) }
# Before patch: 2.3 sec.
# After ptach: 3.0 sec.
```

However, I think that name resolution is typically short enough for the application's runtime. For example, the difference is small for the performance of `URI.open`.

```
100.times { URI.open("https://www.ruby-lang.org").read }
# Before patch: 3.36 sec.
# After ptach: 3.40 sec.
```

## Alternative approaches

I proposed using c-ares to resolve this issue (#19430). However, there was an opinion that it would be a problem that c-ares does not respect the platform-dependent own name resolution.

## Room for improvement

* Currently, this patch works only when pthread is available.
* It might be possible to force to stop the worker threads by using `pthread_cancel`. However, `pthread_cancel` with `getaddrinfo(3)` seems still premature; there seems to be a bug in glibc until recently: https://bugzilla.redhat.com/show_bug.cgi?id=1405071 https://sourceware.org/bugzilla/show_bug.cgi?id=20975
* It would be more efficient to pool worker pthreads instead of creating them each time.




-- 
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/

In This Thread

Prev Next