[Gluster-devel] Threads and locks: tgid vs pid

Corentin Chary corentin.chary at gmail.com
Wed Oct 21 13:16:11 UTC 2009


First, some background:
 - getpid() returns current->tgid which is the pid of the first thread
 - gettid() returns current->pid which is the pid of the current thread
For all threads, getpid() is the same.

>From fuse.h :
> For F_SETLK and F_SETLKW the l_pid field will be set to the pid
> of the process performing the locking operation.
Short: l_pid will always be equal to tgid

> struct fuse_context
>        /** Thread ID of the calling process */
>        pid_t pid;
Short: ctx->pid will always be  thread id (current->pid / gettid())

posix_locks use this pid in same_owner(), but pl_forget will be called
with the pid (current->pid) from the thread who did the close. Locks
granted to other threads, won't be deleted.

This can also affect some other translators.

GlusterFS don't want the Thread ID (current->pid), it needs the Process ID
(current->tgid), at least for

A quick hack to make it work with thread would be to getpgid(ctx->pid),
but this won't work in a lot of case (for example, daemonized process).

You may also want to use the l_pid field in struct flock, but this
won't work because you don't know who will close
the fd and call pl_flush.

Another way is to add a syscall to get the tgid from the pid, but I
don't think this will happens.

The easiest way is to add a tgid field in fuse in order to use
ctx->tgid instead of ctx->pid.

Finally, a quick&dirty fix can be made reading /proc/<ctx->pid>/status
in order to find the Tgid: line.

-- 
Corentin Chary
http://xf.iksaif.net





More information about the Gluster-devel mailing list