The pid_t value delivered by FUSE corresponds to the kernel's lightweight process ID, i.e., the thread ID which would be returned by a gittid(2) call. We convert this into the corresponding process ID, as would be returned by getpid(2), in part because at the time we deliver certain event notifications, the thread may have exited.
At present, the only utility for determining the userspace process ID of a lightweight process (thread) is to parse the thread's status file in procfs.
As an implementation note, I considered leaving this as-is in libprojfs (maybe just changing the name of the struct procfs_event field to tid) and letting the client to do the parsing of /proc/<tid>/status if they require it. In the particular case of VFSForGit, it is required, because otherwise the provider doesn't properly ignore events triggered by its own actions.
And further in the VFSForGit case, performing the status file parsing in the C# callback might work OK, since AFAIK the events where it's important to exclude those generated by the provider itself are for things like file deletions, not file modifications. And it's the latter where we don't have the certainty that the thread, or even the process, which generated a CLOSE_WRITE event is still running when we get the final release op from FUSE ... so it might be OK to defer the thread->process ID mapping to the GVFS provider.
But in the end that seemed a bit fragile, and made some assumptions I wasn't 100% sure of, and I figured we would probably end up wanting to return the process ID in almost all userspace use cases (including for our own libprojfs test suite) in our library API, so I went with this approach for now. Thoughts?
The
pid_tvalue delivered by FUSE corresponds to the kernel's lightweight process ID, i.e., the thread ID which would be returned by agittid(2)call. We convert this into the corresponding process ID, as would be returned bygetpid(2), in part because at the time we deliver certain event notifications, the thread may have exited.At present, the only utility for determining the userspace process ID of a lightweight process (thread) is to parse the thread's
statusfile in procfs.As an implementation note, I considered leaving this as-is in libprojfs (maybe just changing the name of the
struct procfs_eventfield totid) and letting the client to do the parsing of/proc/<tid>/statusif they require it. In the particular case of VFSForGit, it is required, because otherwise the provider doesn't properly ignore events triggered by its own actions.And further in the VFSForGit case, performing the
statusfile parsing in the C# callback might work OK, since AFAIK the events where it's important to exclude those generated by the provider itself are for things like file deletions, not file modifications. And it's the latter where we don't have the certainty that the thread, or even the process, which generated aCLOSE_WRITEevent is still running when we get the finalreleaseop from FUSE ... so it might be OK to defer the thread->process ID mapping to the GVFS provider.But in the end that seemed a bit fragile, and made some assumptions I wasn't 100% sure of, and I figured we would probably end up wanting to return the process ID in almost all userspace use cases (including for our own libprojfs test suite) in our library API, so I went with this approach for now. Thoughts?