[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