ruby-core

[email protected] wrote:
> normalperson (Eric Wong) wrote:
> > [email protected] wrote:
> >  > Would it be simpler to track a set of pids created by MJIT, ignore those in waitpid() and synchronize around both creating GCC processes and when checking the result of waitpid()?
> >  
> >  Not possible, if there's a thread running in waitpid(-1, 0),
> >  it can steal the result of waitpid(mjit_used_by_pid).
> 
> Thank you for the reply.
> I am not sure to understand why it is not possible, could you elaborate a bit more?
> Could the thread running waitpid(-1, 0) then pass that wait result to the MJIT thread, and retry waitpid(-1, 0) in such a case?
> (with careful synchronization as PIDs can be reused, to ensure to correctly classify as MJIT/non-MJIT pid)

I don't think that synchronization is possible; or it'd be far more complex
than it is now.  Calling waitpid to put a thread to sleep can't atomically
release a mutex like pthread_cond_wait can, and potentially sleeping on two
different non-FD objects is deadlock-prone.

Right now, any sleeping is done with cond_wait in the Ruby or MJIT thread.
The timer thread has no changes in the way it sleeps, as it only does
waitpid with WNOHANG

If SIGCHLD exists but it's reliability is a problem on your platform,
perhaps try the polling patch I proposed at [ruby-core:87682]

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