Re: Should fork|clone automatically propagate?

[Andrew Cagney <cagney at redhat dot com>]

Phil Muldoon wrote:
> Hi,
> > Continuing my review of fork|clone observers, and looking for ways to 
> > simplify things, I'm wondering if the behavior of a fork|clone 
> > observer should be to propagate itself to the offspring?  
> Quite the well timed question ;) As this has an impact on the druid 
> setup (ie if you attach to process group Bash, then we have to keep a 
> constant watch for any new Bash processes and add them too). Back when 
> we were looking at program observers we could do the above behavior 
> (except with fork -> fork -> fork -> exec), via custom observers (add 
> a fork observer to this process, and as an action of that observer add 
> a fork|exec observer to its child) but it was always an expensive 
> operation for the gui.
>
> The question for the core behavior is can we have both ;) I can 
> definitely see a requirement for fork|clone observers to propagate to 
> the offspring, but I can see some corner cases where I could not care. 
> How difficult would it be to have two?
I think we need to identify the most common case (from the point of view 
of both the user and the implementation) and then make that efficient; 
the other case can then be implemented in a number of ways.  As you 
suggest, the alternative is to be generic, perhaps adding a 
<<propogate>> bit to not just fork and exec observers, but also the rest?

Was there a specific corner case in mind, and is it something user 
visible or internal, and could it be implemented differently?

For instance, if a user's intent intent is to watch the details of a 
processes clone|fork|exec system calls then a syscall observer (which 
could display arguments et.al.) would be the most effective.  If the 
user's intent was to also have that observer apply to offspring, then 
perhaps they should be enabling propagation using a tick-box, and let 
frysk internally implement that propagation using fork|clone observer 
primitives?

Similarly, if a user's intent is to bind specific events to a program 
then I don't think they care much about how frysk achieves that using 
fork|exec primitives.

On the other hand, if a user is extending frysk adding a new observer, 
then they'll definitely want to know the details.

thoughts?
Andrew