table of contents
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
getpid(2) | System Calls Manual | getpid(2) |
NUME¶
getpid, getppid - obține identificatorul procesului
BIBLIOTECA¶
Biblioteca C standard (libc, -lc)
SINOPSIS¶
#include <unistd.h>
pid_t getpid(void); pid_t getppid(void);
DESCRIERE¶
getpid() returnează identificatorul de proces (PID) al procesului apelant (acest lucru este adesea utilizat de rutinele care generează nume de fișiere temporare unice).
getppid() returnează identificatorul de proces al procesului părinte al procesului apelant. Acesta va fi fie identificatorul procesului care a creat acest proces cu ajutorul fork(), fie, dacă acest proces s-a încheiat deja, identificatorul procesului căruia i-a fost reafiliat acest proces (fie init(1), fie un proces „subreaper” definit prin operația prctl(2) PR_SET_CHILD_SUBREAPER).es).
ERORI-IEȘIRE¶
Aceste funcții au întotdeauna succes.
VERSIUNI¶
Pe Alpha, în loc de o pereche de apeluri de sistem getpid() și getppid(), este furnizat un singur apel de sistem getxpid(), care returnează o pereche de PID și PID părinte. Funcțiile de învăluire getpid() și getppid() ale glibc se ocupă în mod transparent de acest lucru. A se vedea syscall(2) pentru detalii privind machetarea registrelor.
STANDARDE¶
POSIX.1-2008.
ISTORIC¶
POSIX.1-2001, 4.3BSD, SVr4.
Diferențe între biblioteca C și nucleu¶
De la glibc 2.3.4 și până la glibc 2.24 inclusiv, funcția de învăluire glibc pentru getpid() a pus în memoria cache PID-urile, cu scopul de a evita apelurile de sistem suplimentare atunci când un proces apela getpid() în mod repetat. În mod normal, această memorare era invizibilă, dar funcționarea sa corectă se baza pe suportul din funcțiile de învăluire pentru fork(2), vfork(2) și clone(2): dacă o aplicație ocolea funcțiile de învăluire glibc pentru aceste apeluri de sistem utilizând syscall(2), atunci un apel la getpid() în procesul copil ar returna o valoare greșită (mai exact: ar returna PID-ul procesului părinte). În plus, au existat cazuri în care getpid() ar putea returna o valoare greșită chiar și atunci când se apela clone(2) prin intermediul funcției de învăluire glibc. (Pentru o discuție despre un astfel de caz, consultați ERORI in clone(2).) În plus, complexitatea codului de memorare în cache a fost sursa câtorva erori în cadrul glibc de-a lungul anilor.
Din cauza problemelor menționate mai sus, începând cu glibc 2.25, memoria cache PID este eliminată: apelurile către getpid() invocă întotdeauna apelul de sistem real, în loc să returneze o valoare din memoria cache.
NOTE¶
Dacă părintele apelantului se află într-un spațiu de nume PID diferit (a se vedea pid_namespaces(7)), getppid() returnează 0.
Din perspectiva nucleului, PID-ul (care este partajat de toate firele de execuție dintr-un proces cu mai multe fire de execuție) este uneori cunoscut și sub numele de identificatorul grupului de fire de execuție (TGID). Acest lucru contrastează cu identificatorul de fire de execuție din nucleu (TID), care este unic pentru fiecare fir de execuție. Pentru mai multe detalii, consultați gettid(2) și discuția despre fanionul CLONE_THREAD din clone(2).
CONSULTAȚI ȘI¶
clone(2), fork(2), gettid(2), kill(2), exec(3), mkstemp(3), tempnam(3), tmpfile(3), tmpnam(3), credentials(7), pid_namespaces(7)
TRADUCERE¶
Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu <remusgabriel.chelu@disroot.org>
Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO RESPONSABILITATE.
Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-ro@lists.sourceforge.net.
2 mai 2024 | Pagini de manual de Linux 6.8 |