Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Likely I did not yet get the full picture: What prevents using another
>  > adeos per-task key for this? 
> 
> We would need a per-task key for every skin that needs a per-process
> data,

Not necessarily, we could attach a chain of per-skin data objects to the
key pointer.

> but more importantly, we would need to track the clone syscalls
> (that would be another adeos event) in order to propagate the per-task
> data to each thread of the process. Or maybe ptds are inherited upon
> clone ?

Ok, I see the problem, no hook to save here.

> 
> And why is it required to establish a new
>  > termination hook? Are there scenarios where the existing
>  > task-termination hook is not suited for the planned cleanup work?
> 
> Because the existing hook is called once for every thread exit, whereas
> the pexit event get triggered when the last thread of a process exits,
> this is the only moment we are sure we can destroy per-process data.
> 
> Using the existing hook, we would need to decrement a reference counter
> in the hook, but then we would (again) need to track the clone syscalls
> in order to increment the reference counter.
> 
> Both implementations require to add an adeos event, the one I chose, if
> it works, avoid reference counting.
> 

My motivation for suggesting the keys were avoiding the
hash-table-lookup for mm structs. If we maintain some pointer on a
per-thread basis, we would only have to walk over all skins, not all
colliding elements in a hash chain.

I cannot show any code to compare both approaches w/ complexity and
efficiency. Maybe your approach is actually leaner, but my feeling is
that something based on per-task pointers might have advantages as well.

Moreover, having a clone hook may open further doors: establishing hooks
to clone shadow threads...

Jan