|

»

Threads and locks: tgid vs pid

View: New views

3 Messages — Rating Filter: Alert me

	Threads and locks: tgid vs pid by Corentin Chary-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel
	Re: Threads and locks: tgid vs pid by Corentin Chary-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Wed, Oct 21, 2009 at 3:16 PM, Corentin Chary <corentin.chary@...> wrote: > 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 > Reading the fuse source, I found the solution: fuse_file_info->lock_owner should be used to check ownership instead of pid. This way the pid/tgid thing is no more an issue. Patch comming tomorow =) -- Corentin Chary http://xf.iksaif.net ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel
	Re: Threads and locks: tgid vs pid by Corentin Chary-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Wed, Oct 21, 2009 at 7:11 PM, Corentin Chary <corentin.chary@...> wrote: > On Wed, Oct 21, 2009 at 3:16 PM, Corentin Chary > <corentin.chary@...> wrote: >> 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 >> > > Reading the fuse source, I found the solution: > fuse_file_info->lock_owner should be used to check ownership instead of pid. > This way the pid/tgid thing is no more an issue. > Patch comming tomorow =) Reading more glusterfs code lead me to this conclusion: - lock_owner can be used for fuse, but to use that we need to add lock_owner to _call_stack_t or add lock_owner to gf_flock and use it everywhere instead of struct flock. For libglusterfs_client and booster we can probably use getpid() to fill lock_owner. - glusterfs fs need* the tgid for fd_create/fd_lookup So, patch not comming tomorow, because I'm not sure what's the best way to fix that. -- Corentin Chary http://xf.iksaif.net ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ fuse-devel mailing list fuse-devel@... https://lists.sourceforge.net/lists/listinfo/fuse-devel