Pidfd

Line 1:

Since [[Linux_APIs|Linux 5.2]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.

At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with tt>clone3(2)</tt>.

At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.

Pidfd: Difference between revisions

Dank (talk | contribs)

Revision as of 19:10, 30 June 2023 view source Dank (talk \| contribs) Bureaucrats, Administrators 11,325 edits Created page with "Since Linux 5.2, pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities. At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a t..."		Revision as of 19:11, 30 June 2023 view source Dank (talk \| contribs) Bureaucrats, Administrators 11,325 edits No edit summary Newer edit →
Line 1:		Line 1:
	Since [[Linux_APIs\|Linux 5.2]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.		Since [[Linux_APIs\|Linux 5.2]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.

	At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with tt>clone3(2)</tt>.		At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.