Date | Commit message (Collapse) |
|
This gives us thread-safety for the internal buffer. While
we're at it, cache-align this buffer to avoid unnecessary
overhead when read() writes to it.
|
|
ENOMEM from syscalls such as inotify_add_watch and epoll_ctl are
from the lack of kernel memory, so even a successful rb_gc() is
unlikely to be able to reap memory taken from those slab caches.
|
|
This probably won't make a huge difference in Ruby, but perhaps
one day the unnecessary dirtying of cache lines will affect
performance (and we'll be ready when that day comes).
While we're at it, remove usage of pthread* functions for
thread-local variables. The __thread construct from GCC (and
also implemented by clang) is much easier-to-use than the
pthread_*specific API.
|
|
Epoll::IO is a dangerous, low-level class which is intended
for users aware of the GC and fork behavior of epoll in the
Linux kernel.
Rewriting the higher-level Epoll in Ruby makes it easier to
maintain, especially since Rubinius has no GVL while running
C extensions.
|
|
I was about to change this to the FIONBIO here myself before
I realized we do not frequently _change_ file flags.
|
|
The file descriptor may be closed while GVL is released,
so we must reload the descriptor before and after calling
rb_io_wait_*able functions.
We reload before calling rb_io_wait_*able because the GVL was
released for the function call (read/write) which triggered
EAGAIN.
We reload after calling rb_io_wait_*able because
rb_io_wait_*able releases the GVL, too.
|
|
We forgot to update this documentation when we released 3.1.0
|
|
pthread_once_t must be static to be effective. This bug only
affects apps which load sleepy_penguin multiple times.
|
|
This was added in Linux 3.5 and glibc 2.17
|
|
This reverts commit 02e5a91b24983d96b342c007661966495ccdb619.
This workaround may have unintended side-effects for apps using
EPOLL_CTL_DEL.
|
|
Until everybody updates to a version of the Linux kernel with
this fix, we need to enable a workaround for older kernels using
EPOLL_CTL_DEL + EPOLL_CTL_ADD to emulate EPOLL_CTL_MOD behavior.
This race condition is fixed in Linux upstream
commit 128dd1759d96ad36c379240f8b9463e8acfd37a1 and included in
Linux v3.8-rc2 and later.
This fix will likely be backported to stable and vendor kernels,
so we'll whitelist them as we learn of them.
|
|
timerfd currently (Linux 3.3.x) only supports CLOCK_REALTIME and
CLOCK_MONOTONIC, and not every single clock supported by POSIX
clocks.
|
|
It's POSIX, and since epoll is Linux-only and Linux
uses glibc which is pretty up-to-date w.r.t POSIX,
we don't have to worry...
|
|
This allows multiple threads to park on Epoll#wait (without
holding onto the GVL). This allows a single, one-shot notification
to wake up a single thread (another notification to a different
IO object would wake up another thread).
This allows using the same multi-threaded, EPOLLONESHOT-based
design as cmogstored:
http://bogomips.org/cmogstored/queues.txt
|
|
This function is exposed in the libruby-static archive for
Ruby 1.9.3, but there is no publically-declared prototype for it.
|
|
It's ugly and confusing to look at, so split it out.
|
|
It's a waste of memory to have something that has no chance
of working reliably with any existing Ruby runtimes.
|
|
This is the only descriptor we manage ourselves and don't
use IO.for_fd with (epoll is quite "special" wrt fork).
|
|
Oops...
|
|
We still need to document these.
ref: http://www.man7.org/tlpi/api_changes/
|
|
Even if we timeout while getting an EINTR, we'll retry
epoll_wait() with a zero timeout like IO.select does in Ruby to
avoid raising Errno::EINTR.
|
|
It's too dangerous in the general case to support, and
we doubt people ever used it.
|
|
We don't want to operate on improper FDs in multithreaded
environment. This affects MRI despite the GVL since file
descriptors are usually allocated without the GVL held
(open()/accept()).
|
|
Really, don't do it.
|
|
It's too incompatible with the way Ruby handles signals.
|
|
It's fewer lines of code and cleaner in cases where "new"
and "for_fd" are the same underlying method.
|
|
Makes error reporting easier, we think.
|
|
It's more consistent with IO#read/IO#write/IO.select in MRI.
|
|
|
|
We should get this fixed properly in MRI, and Inotify
descriptors aren't often closed anyways...
|
|
rb_thread_fd_close is in both MRI 1.8 and MRI 1.9.3dev
|
|
ref: Linux kernel sources
|
|
Yes, people still use 32-bit machines
|
|
Stupid typo :x
|
|
May not detected properly
|
|
Probably not an issue under Linux
|
|
Ruby 1.9.3 will release the GVL for IO#close
|
|
|
|
close(2) on inotify descriptors takes forever and a day.
|
|
This is useful for processing events in a synchronous fashion,
we think...
|
|
"in" is a keyword in Ruby and unusable as a local variable
|
|
I know of no other way to support them in Ruby
|
|
Instead, allow a nonblock flag to be passed to
EventFD#incr and EventFD#value so it matches other
interfaces.
|
|
Just like Inotify#take
|
|
|
|
Not that it works well...
|
|
Avoids using select(2) if we want blocking functionality on
Ruby 1.9.
|
|
They could be useful for other projects.
|
|
Just reuse 1.9 methods
|
|
Never used anywhere
|