takashikkbn / gmail.com wrote:
> Thank you for your quick and detailed reply. For 1, I'll try
> to acquire GVL from MJIT worker thread to resolve this issue.
> In that case possibly we could just synchronously finish the
> copy job during the lock and avoid using postponed_job.

Acquire GVL from non-Ruby Thread doesn't seem possible, but
making MJIT thread into a Ruby Thread may simplify the code,
actually.

However, I don't understand why copy_cache_from_main_thread
needs to be done at all.  I haven't looked at it in detail, but
it adds extra synchronization overhead for a slightly more
up-to-date cache, right?

Back-and-forth synchronization between threads kills parallelism
and likely defeats the purpose of MJIT worker having its own
thread.

So I think two options are worth experimenting with:

1. Copy cache when enqueueing during mjit_add_iseq_to_process,
   give up on up-to-dateness of IC/CC.  This should be easy
   and simplify existing code, even.

2. Get rid of MJIT worker thread and rely on SIGCHLD + non-blocking waitpid.
   I don't know the portability problems in Windows, though.

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