Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112015-02-26T11:36:32ZRuby Issue Tracking System
Redmine Ruby master - Bug #10908 (Rejected): Addrinfo.new appears to ignore the afamily argument when usi...https://bugs.ruby-lang.org/issues/109082015-02-26T11:36:32Zyorickpeterse (Yorick Peterse)yorickpeterse@gmail.com
<p>When creating a new <code>Addrinfo</code> instance the <code>new</code> class method appears to ignore<br>
the 2nd (afamily) argument and always sets it to <code>AF_INET</code>. Some examples:</p>
<pre><code>Socket::AF_INET # => 2
Addrinfo.new(Socket.sockaddr_in(80, 'localhost')).afamily # => 2
Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::AF_INET6).afamily # => 2
Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::PF_UNSPEC).afamily # => 2
Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::AF_IPX).afamily # => 2
Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::AF_LOCAL).afamily # => 2
</code></pre>
<p>Is this correct, or is this a bug?</p>
<p>The documentation states the following about this argument:</p>
<blockquote>
<p>family is specified as an integer to specify the protocol family such as<br>
Socket::PF_INET. It can be a symbol or a string which is the constant name<br>
with or without PF_ prefix such as :INET, :INET6, :UNIX, "PF_INET", etc. If<br>
omitted, PF_UNSPEC is assumed.</p>
</blockquote>
<p>I looked at the tests but couldn't find any specific examples of this behaviour.<br>
For Rubinius I ended up writing the following Rubyspec which currently passes on<br>
both Rubinius (you'll need the Git master branch for this, for now) and Ruby<br>
2.2: <a href="http://git.io/AhpQ" class="external">http://git.io/AhpQ</a>. I've attached the spec as well in case the URL stops<br>
working.</p> Ruby master - Misc #10907 (Rejected): Documentation of Addrinfo.new suggests default family of PF...https://bugs.ruby-lang.org/issues/109072015-02-26T11:27:15Zyorickpeterse (Yorick Peterse)yorickpeterse@gmail.com
<p>The documentation of Addrinfo.new states the following:</p>
<blockquote>
<p>family is specified as an integer to specify the protocol family such as<br>
Socket::PF_INET. It can be a symbol or a string which is the constant name<br>
with or without PF_ prefix such as :INET, :INET6, :UNIX, "PF_INET", etc. If<br>
omitted, PF_UNSPEC is assumed.</p>
</blockquote>
<p>However, the behaviour contradicts this:</p>
<pre><code>Addrinfo.new(Socket.sockaddr_in(80, 'localhost')).afamily == Socket::PF_UNSPEC # => false
Addrinfo.new(Socket.sockaddr_in(80, 'localhost')).afamily == Socket::AF_INET # => true
</code></pre>
<p>The question here is, which of the following is the case:</p>
<ol>
<li>The documentation is simply incorrect, the default is always <code>AF_INET</code>
</li>
<li>The behaviour is incorrect, it should be <code>PF_UNSPEC</code> instead of <code>AF_INET</code>
</li>
<li>This is platform specific (meaning the documentation should state this)</li>
</ol>
<p>On Twitter Matz mentioned<br>
(<a href="https://twitter.com/YorickPeterse/status/570700823526830080" class="external">https://twitter.com/YorickPeterse/status/570700823526830080</a>) thinking it was<br>
platform specific, but I'd like to be 100% sure about this.</p> Ruby master - Feature #8619 (Open): Standard Profiling APIhttps://bugs.ruby-lang.org/issues/86192013-07-10T19:51:29Zyorickpeterse (Yorick Peterse)yorickpeterse@gmail.com
<p>At the time of writing there are many different Ruby implementations ranging<br>
from the common ones such as MRI, Jruby and Rubinius to slightly less common<br>
ones such as mruby and Topaz.</p>
<p>A recurring problem in all these implementations is that there's no standard<br>
API for profiling resource usage. For example, for MRI there's ruby-prof but in<br>
order to get garbage collection and memory usage related information you have<br>
to patch MRI. As far as I'm aware of Jruby is the only implementation that at<br>
this point offers proper tools for profiling your Ruby application as it piggy<br>
backs on top of the JVM and all the awesome profiling tools that come with it.</p>
<p>What I'd hereby like to propose is an API for all Ruby implementations that<br>
allows developers to profile at least the following:</p>
<ul>
<li>Garbage collection information</li>
<li>Memory usage</li>
<li>Object allocations</li>
</ul>
<p>These items are discussed in detail below.</p>
<a name="Topics"></a>
<h2 >Topics<a href="#Topics" class="wiki-anchor">¶</a></h2>
<a name="Garbage-Collection"></a>
<h3 >Garbage Collection<a href="#Garbage-Collection" class="wiki-anchor">¶</a></h3>
<p>In the past one would have to use REE or install a bunch of patches in order to<br>
get GC information such as when it would run, how many objects it processed,<br>
etc. What I'd like to see here is the following:</p>
<ul>
<li>When the GC starts/stops</li>
<li>How many objects are freed and how many are left intact</li>
<li>The time it takes for the GC to run</li>
</ul>
<p>If applicable there could be more added, this is just what I can think of from<br>
the top of my head.</p>
<a name="Memory-Usage"></a>
<h3 >Memory Usage<a href="#Memory-Usage" class="wiki-anchor">¶</a></h3>
<p>Next to the GC this is a particular important addition. Similar to GC<br>
information one would have to install MRI patches to get memory usage<br>
information or worse, use something along the lines of the following:</p>
<pre><code># Returns memory usage of the entire process in KB
def memory_usage
return `ps -o rss= #{Process.pid}`.strip.to_f
end
</code></pre>
<p>The above code is actually fairly common but also inaccurate and adds a pretty<br>
big overhead as a subshell has to be started for every call. It also wouldn't<br>
work on systems where <code>ps</code> is not available or would otherwise work<br>
differently.</p>
<p>Ideally one should be able to get the memory usage of individual memory calls<br>
similar to what you can now achieve using ruby-prof + a set of patches. This<br>
would greatly reduce the amount of time and effort required to hunt down memory<br>
leaks or otherwise memory intensive operations when it's not entirely clear why<br>
something is not performing as well as it should.</p>
<a name="Object-Allocations"></a>
<h3 >Object Allocations<a href="#Object-Allocations" class="wiki-anchor">¶</a></h3>
<p>This one goes a bit hand in hand with the memory usage topic. Ideally one<br>
should be able to get the amount of allocated objects per method call in a bit<br>
more accurage way than ObjectSpace currently provides. For example, it would be<br>
nice if one could see that method X allocated 2500 String objects, 2 Array<br>
Objects and 1 Foo::Bar object.</p>
<a name="API-Design"></a>
<h2 >API Design<a href="#API-Design" class="wiki-anchor">¶</a></h2>
<p>Code wise I'm not entirely sure how this would look, which is part of why I'm<br>
opening this feature request. I'm thinking out loud here but I was thinking of<br>
something along the lines of the following:</p>
<pre><code>require 'profiler/memory'
require 'profiler/allocations'
require 'profiler/gc'
# The same would be used for memory and allocation profiling but using
# different constants (e.g. MemoryProfiler and AllocationProfiler)
GC.enable_profiling
# Do some serious Ruby work here
# Here `result` would contain the profiling results per method call made
# since profiling was enabled.
result = GC.disable_profiling
</code></pre>
<p>The core idea however is that every Ruby implementation would offer the same<br>
public API (though the internals may differ). This way one could write a tool<br>
that for example displays a graph of the memory usage over time that would work<br>
in all the Ruby implementations. Currently this is not something that's<br>
possible due to the vastly different APIs (or total lack thereof).</p>
<p>Note that this request isn't a "I want this and I want it now" request but more<br>
the start of a discussion about such an API. The amount of time and effort<br>
required to get this to work on the various implementations could easily take<br>
months if not a few years (heavily depending on the amount of people<br>
available). Especially if you consider that some implementations might<br>
currently not even make the required information publically available.</p>
<p>So to cut a long story short: I hereby open the discussion on a common API for<br>
profiling resource usage in the varios Ruby implementations.</p>
<p>p.s. Although I'd also be interested in seeing execution time of methods and<br>
such I'm not entirely sure how I'd envision such an API. As such I've left it<br>
out of this request but of course everybody is welcome to discuss/include that<br>
as well.</p>