sam.saffron / gmail.com wrote:
> I really really like this, its a free performance boost with
> almost no downsides. 

Almost...  I need to revisit [PATCH 4/2] (native_sleep) due to
th->status changes and finalizers running causing compatibility
problems.

> I guess the simplest way of measuring it would be to run
> something like Discourse bench with and without the patch. In
> theory we should get better timings after the patch cause it
> decreases odds that the various GC processes will run when the
> interpreter wants to run Ruby. 

Depends on benchmark, if a benchmark is pinning things to 100%
CPU usage then I expect no improvements.  But I don't think
real-world network servers are often at 100% CPU use.

> Implementation wise it seems like you only have it on
> rb_wait_for_single_fd

PATCH 3/2 added select() support, too

> , is there any way you can make this work
> with the pg gem? It just builds on libpq per:
> https://www.postgresql.org/docs/8.3/static/libpq-async.html so
> maybe you would need to expose an end point for libpq to
> "trigger" partial gc processes just when you send a query? 

I'd need to look more deeply, but I recall 'pg' being one of the
few gems which worked well with 1.8 threads because FDs were
exposed for Ruby to select() on.

So I'm not sure what they're doing these days where they give
the Ruby VM no way to distinguish between waiting on external
resource (FD) or doing something CPU-intensive locally.

I guess you can cheat for now and do:

	Thread.new do
	  r, w = IO.pipe
	  loop { r.wait_readable(0.01) }
	end

Which will constantly do incremental mark + lazy sweep.  But
cross-thread free() is probably still bad on most malloc
implementations...

If 4/2 worked reliably (tests pass, though...)):

   Thread.new { loop { sleep(0.01) } }

(gotta run, back later-ish)

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>