[#99868] [Ruby master Bug#17144] Tempfile.open { ... } does not unlink the file — eregontp@...
Issue #17144 has been reported by Eregon (Benoit Daloze).
15 messages
2020/09/03
[ruby-core:100072] Re: [Ruby master Feature#17059] epoll as IO.select
From:
Eric Wong <normalperson@...>
Date:
2020-09-22 17:43:15 UTC
List:
ruby-core #100072
[email protected] wrote: > Feature #17059: epoll as IO.select > https://bugs.ruby-lang.org/issues/17059 Try ppoll(2) to replace IO.select, instead. It also works on newer FreeBSD. To use epoll(7) effectively, you really need a scheduler API and probably restructure programs. Furthermore, the Level-Triggered (default) epoll behavior seems to be cause for many complaints and FUD about epoll in general. I recommend sticking to EPOLLONESHOT mostly, and EPOLLET for unidirectional cases. * EPOLLONESHOT - easiest for bidirectional sockets, hard to get wrong once you use it * EPOLLET - Use it for listen sockets, pipes and FIFOs. That is, one-way stuff that's always EPOLLIN or EPOLLOUT-only, but can never be BOTH EPOLLIN or EPOLLOUT. Theoretically it could be faster than EPOLLONESHOT for bidirectional sockets due to fewer syscalls, but tricky-to-use as it depends on client traffic patterns (which clients can abuse). Fwiw: I've read and understood fs/eventpoll.c in the Linux source; it's fairly self-contained and should be easy-to-understand to anybody remotely familiar with C. There's a lot hate on epoll out there and I strongly suspect the default (level-trigger) behavior is to blame. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>