| Date | Commit message (Collapse) |
|---|
|
Currently, all memory used by Raindrops is mapped as MAP_ANONYMOUS. This
means that although Raindrops counters can be shared between processes
that have forked from each other, it is not possible to share the
counter values with another, unrelated process.
This patch adds support for backing the Raindrops mapping with a file
descriptor obtained from an IO object. The #initialize API has been
enhanced with two new keyword options:
Raindrops.new(size, io: nil, zero: false)
If an instance of IO is provided, then the underlying file descriptor
for that IO will be used to back the memory mapping Raindrops creates.
An unrelated process can then open the same file, and read the counters;
either by mmap'ing the file itself (or using Raindrops to do so), or by
making ordinary seek()/read() calls if performance is not a concern.
Note that the provided IO object _must_ implement #truncate; this is
used to set the size of the file to be right-sized for the memory
mapping that is created.
If the zero argument is passed as true, then the mapping will be zero'd
by Raindrops as part of its initialization. If it's false, then the
Raindrops counters existing in the file will be preserved. This allows
counter values to be persisted (although note that Raindrops makes no
attempt to msync the values, so they are not durable to e.g. system
crashes).
Counter values can easily be shared between processes
in-memory only without touching the disk by passing in a File on a
tmpfs as the io object.
|
|
* origin/freebsd:
define Raindrops::TCP hash for TCP states
tcp_info: support this struct under FreeBSD
|
|
errno is in the thread-specific section and it is slightly
cheaper to read it once rather than twice. Recent versions
of mainline Ruby itself follows the same pattern.
|
|
Of course these fields are not portable between Linux and FreeBSD,
but they should remain ABI-compatible for future versions of each OS.
Tested on FreeBSD 10.3-RELEASE i386
TCP state names will be another problem...
|
|
This provides some extra type safety if combined with other
C extensions, as well as allowing us to account for memory usage of
the HTTP parser in ObjectSpace.
This requires Ruby 1.9.3+ and has remained a stable API since
then. This will become officially supported when Ruby 2.3.0 is
released later this month.
This API has only been documented in doc/extension.rdoc (formerly
README.EXT) in the Ruby source tree since April 2015, r50318
|
|
The runnable CPUs of a process may change over the lifetime of
the process. So favor the count of configured processor count
since that is more likely to be stable.
We do not currently do not have special handling for
hot-plugging/removal of CPUs on systems that may load raindrops
in a single CPU state.
|
|
We can't have negative values
|
|
Oops, it could give the GC problems.
|
|
This allows limited resizing of the Raindrops memory
area since we always over-allocate due to the required
page aligment for mmap.
It would be nice if mremap() worked with MAP_SHARED,
but it does not and triggers a bus error when attempting
to access the new area.
ref: https://bugzilla.kernel.org/show_bug.cgi?id=8691
|
|
Of course, RDoc doesn't know quantity vs quality :)
|
|
This is the highest number a counter may be incremented to
before it overflows.
|
|
This returns a Raindrops::TCP_Info object
that wraps a tcp_info struct.
|
|
Modern glibc can easily return the L1 cache line size with
sysconf(3), so we'll use that and avoid paying a size penalty on
CPUs with smaller cache lines than 128 (every modern x86 except
the idiotic P4).
Additionally, if we detect a single CPU machine, avoid paying
any padding penalty at all.
On machines without the non-portable glibc sysconf(3)
enhancements, we'll continue to operate on the assumption
of an enormous 128 byte cache line size.
|
|
This allows non-GCC 4.x users to experience Raindrops.
|
|
This is only possible during an exit if our invocation of
rb_gc() fails and causes the process to terminate. Otherwise
the GC won't free something that's obviously on the stack.
|
|
|