Re: frysk-core/frysk/proc LinuxTask.java TestProcS ...

[Mark Wielaard <mark@klomp.org>]

On Wed, 2006-10-11 at 18:33 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> > Aha. So we are trying to trick our own waitpid() into thinking it
> > received a new SIGCHLD event? But aren't we actually waiting for a
> > SIGSTOP from the child after an ptrace attach?
> >  
> A waitpid doesn not receive a SIGCHLD event, rather the arrival of a 
> waitpid event normally leads to the controlling process being sent a 
> SIGCHLD.

Aha! That explains our PollWaitOnSigChld SignalEvent handler in
LinuxHost. I had never understood this step. Finally all the pieces are
starting to come together and make sense. I always assumed a SIGCHLD was
only send for child terminated events.

Still surprising we have kind of a double bookkeeping here. For each
(traced) child event we get a signal and we have to poll waitpid().
That does sound like high overhead.

> Nurden's patch, which is simple and elegant, fudges the case of SIGCHLD 
> not being sent by sending one anyway.

OK, that just leaves one question:

> > Is sending the signal to our calling Thread as good as sending to any
> > other Thread in our frysk process?

Since we use tkill() on the calling Thread that seems to mean we are
explicitly sending to a particular task and that might not be the one
that has installed the signal handler. So how does that get at the right
place?

BTW. Slightly related, there is a bug/enhancement report for libgcj to
provide signal chaining:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25655
And another one for adding a wait handling hook:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
Those might be nice for us, so we can use more of the standard core
library. But I don't believe anybody is working on those atm.

Cheers,

Mark