This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stap vs pgrps


Roland McGrath wrote:
> So, what would foobargui be complaining about if foobar were implemented as
> a shell script that used some background processes and "wait"?  The same
> thing, but perhaps it would be immediately obvious that foobargui was the
> one in the wrong.  
> 
> I have not looked at stapgui's context in detail to recommend what in
> particular it ought to be doing instead.  Since I see it's entirely written
> in Eclipsese, we may need to consult with our Eclipse experts to work it out.

Let's not focus on the particular red herring of Eclipse.  Suppose this
was our stapgui:

  $ cat stapgui.sh
  #!/bin/sh
  echo starting stapgui
  stap -ve 'probe begin, end { println(pp()) }' &
  stappid=$!
  sleep 10
  kill -TERM -$stappid
  wait $stappid
  echo stapgui done

I tried to do the right thing here by killing -$stappid for stap's whole
pgrp, but the real pgrp is actually $$.  I don't want to kill -$$
though, because then the whole GUI would die and I wouldn't get my final
echo. :(

Perhaps you'll tell me next how to run stapgui.sh with job control
enabled in sh.  Well, replace sh with C/C++/Java/Python/etc., and you'll
have to manage pgrps all over again, which is the aforementioned can of
droid worms we don't want to touch...

That's why I do think stap needs to care, rather than trying to pass the
buck up to the caller.

> The EINTR check only makes sense if you have used sigaction for signals of
> concern to install handlers that disable SA_RESTART behavior so you will
> actually get the EINTR.  
> 
> When that's so, you'll hit this case for a signal that won't be fatal too,
> e.g. for SIGTSTP/SIGCONT after you resume (even if those weren't handled).
> So the normal method is to loop, and only do the kill based on testing a
> flag set by a signal handler.

We have such a flag already, but I was worried about the race between
checking it and blocking on waitpid again.  I suppose I still have a
race anyway, so how can you manage this?  Or is the collision just so
rare that no one bothers?

Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]