Re: [PATCH] Linux: Implement per-thread file system attributes

[Carlos O'Donell <codonell at redhat dot com>]

On 4/10/19 11:15 AM, Florian Weimer wrote:
> This commit adds the functions pthread_attr_setperthreadfs_np and
> pthread_attr_getperthreadfs_np.
>
> The implementation is based on suppressing the CLONE_FS clone flag when
> creating the new thread.
> -----
> Changes from the previous version:
>
> - rebased to glibc 2.30
> - some documentation in the manual
> - closer alignment to other pthread attributes
>    (e.g. the pshared flag handling)
>
> If approved, I will put the support/ bits into a separate commit.

I haven't gone through the whole patch yet, but something specific came
to mind as I read through the API semantics.

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)?

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

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).

Is (a) possible?

If (a) is not possible, it's interesting to ask the following question
as a programming:

* Given the current thread.
* Does it share the filesystem attributes with the process?
* If it does, then take certain steps to avoid stomping on it.
* If it doesn't, then do whatever you want.

The problem here is this:
pthread_create (PTHREAD_PER_THREAD_NP) -> Thread A.
Thread A -> pthread_create (PTHREAD_PER_PROCESS_NP) -> Thread B.
Thread B -> Library tries to determine if it's sharing or not with the whole process.

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.

Should (b) be considered? Should we store the value of the parent task
into the attribute structure in some way? Or only store a bit to
indicate that we are in a distinct set from the process itself?

It may be that this doesn't matter and that in the future we'll just
need a new API for this kind of query if it becomes relevant.

I'm just looking at the broader design to see if it impacts any
choice you have to make today.

--
Cheers,
Carlos.