"Atdot.net" <ko1 / atdot.net> wrote:
> Could you give us more detail algorithm?

Pretty simple and I thought the patch was easy-to-read.

Background is we can use ppoll with zero-timeout
({.tv_sec = 0, .tv_nsec = 0 }) to check and return immediately
w/o releasing GVL.  This means we can quickly check FD for
readiness.

This is a quick check and even optimized inside the Linux kernel[1].

thread_pthread.c also tracks GVL contention using .waiting field.

I define GC-in-progress as (is_lazy_sweeping || is_incremental_packing)
(same condition for gc.c:gc_rest() function)

Therefore, if GVL is uncontended and GC has work to-do, we use
zero-timeout ppoll and do incremental GC work (incremental mark
+ lazy sweep) as long as we need to wait on FD.

If GC is done or if there is GVL contention, we fall back to use
old code path and release GVL.


For do_select case, it might be more expensive because select()
is innefficient for high FDs; but if a process is otherwise not
doing anything, I think it's OK to burn extra cycles to perform
GC sooner.

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