This is the mail archive of the mailing list for the glibc 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: [PATCH] Linux: Implement per-thread file system attributes

* Carlos O'Donell:

> Any child created with CLONE_FS will have per-thread properties, that's
> clear and easy to understand.
> However, in the case of !CLONE_FS you will have a set of descendants
> which all share the same properties (not those of the process itself).
> (a) Is there any desire to want to create a new thread that has the same
>     shared properties as that of the process (not that of the parent
>     task)?

I doubt we'll ever need it.  We could implement it with a separate
helper thread with a tiny stack, specifically serving such requests (and
which is created the first time per-thread attributes are created).  I
don't think we need to implement it right now.

(The setxid mechanism could be used as well, but we probably do not want
to pile more functionality onto it.)

> (b) Is there any need to identify the parent that created the set of
>     descendants that share all the same filesystem properties?

We do not have a unique identifier for the parent thread, so I don't
think that can be implemented today.

With my TID patches and kcmp with KCMP_FS, it will be possible to test
if two running threads share the same file system attributes.

> If (a) was possible, and I don't think it is given the current linux
> interfaces, then when you have "PTHREAD_PER_PROCESS_NP" it would really
> do what the name says, and attach the thread's fs-attributes to the
> process (not the most recent set of descendant children from a parent
> task that set this value).

I think that would be super-confusing because the net effect will be
that pthread_create changes these attributes (in the sense that the new
thread starts out with different values).

> A library, with an outside view, can't tell, by accessing the
> thread attributes via pthread_getattr_np(), if it shares with
> the process or not because PTHREAD_PER_PROCESS_NP will bet set.

True, but one of the threads may have called unshare, so you need kernel
support anyway.

We could also make PTHREAD_PER_THREAD_NP sticky in the sense that *all*
descendent threads have it set automatically, nom atter what the
attribute requests.  This is what we need to implement for user and
group IDs, as discussed before.  We could also add a third flag for the
non-sticky behavior.


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