PID max ?

Le
JKB
Bonjour à tous,

Je suis en train de me poser une question bête Comment connaître
de façon _portable_ le PID maximal sur un système donné ? POSIX dit-il
quelque chose là-dessus ? Je n'ai rien trouvé de probant

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Stephane CHAZELAS
Le #17886071
2008-11-18, 18:32(+00), JKB:
[...]
Je suis en train de me poser une question bête... Comment connaître
de façon _portable_ le PID maximal sur un système donné ?



Je ne sais pas, mais dans quel contexte as tu besoin de cette
information. Note que sous Linux, ca peut varier puisque c'est
configurable au run-time dans certaines limites
(/proc/sys/kernel/pid_max)

POSIX dit-il quelque chose là-dessus ?


[...]

Juste que pid_t est un signed integer (width pas precisée)
AFAICT.

--
Stéphane
JKB
Le #17889161
Le 18-11-2008, ? propos de
Re: PID max ?,
Stephane CHAZELAS ?crivait dans fr.comp.os.unix :
2008-11-18, 18:32(+00), JKB:
[...]
Je suis en train de me poser une question bête... Comment connaître
de façon _portable_ le PID maximal sur un système donné ?



Je ne sais pas, mais dans quel contexte as tu besoin de cette
information. Note que sous Linux, ca peut varier puisque c'est
configurable au run-time dans certaines limites
(/proc/sys/kernel/pid_max)



C'est très simple. Dans un énorme bout de code, j'ai un tas de
fork() et j'aimerais remplacer certains fork() par des pthread_create().
Tous les pids sont stockés au final dans des uint64 et je me demandais
bêtement si je pouvais brutalement utiliser les 32 bits de poids faibles
pour un pid (dans le cas d'un fork) et les 32 bits de poids forts pour
les tid (dans le cas d'un pthread_create). Si pid_t est un signed (?)
int, cela risque d'être casse gueule. /me va donc utiliser une union
avec un drapeau quelconque...

POSIX dit-il quelque chose là-dessus ?


[...]

Juste que pid_t est un signed integer (width pas precisée)
AFAICT.



Autre question un peu connexe... J'ai cherché si POSIX stipulait
quelque chose à propos de l'exécution des threads (créés of course par
libpthread, je ne parle pas des threads Linux ou Solaris). A-t-on
l'assurance que sur une machine à plusieurs processeurs les threads
peuvent s'exécuter sur des processeurs différents ? Sur certaines
implantations, tous les threads s'exécutaient sur le même processeur que
le processus père...

J'explique mon problème : je travaille sur des problèmes
d'optimisation avec des blocs de données (cartographie) qui font un peu
moins de 2 Go. En faisant un fork(), je consomme le double de mémoire
(même avec l'histoire de copy on write, parce qu'il y a une petite
manipulation faite sur les données). Utiliser la mémoire partagée posix
ne me semble pas une bonne idée (problème de taille). L'idée est donc
d'utiliser des threads pour éviter une utilisation sous-optimale de la
mémoire, mais il faut encore que je sois assuré que les threads
s'exécuteront bien sur des processeurs différents (sinon l'occupation
mémoire sera moindre, mais au détriment de la vitesse d'exécution...).

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
talon
Le #17890641
JKB
ne me semble pas une bonne idée (problème de taille). L'idée est donc
d'utiliser des threads pour éviter une utilisation sous-optimale de la
mémoire, mais il faut encore que je sois assuré que les threads
s'exécuteront bien sur des processeurs différents (sinon l'occupation
mémoire sera moindre, mais au détriment de la vitesse d'exécution...).




En principe c'est le scheduler qui s'occupe de répartir les threads sur
les processeurs disponibles, et tu n'as pas de contrôle là dessus.
Cependant sur certains systèmes tu peux demander à ce qu'une "affinité"
soit respectée, c'est à dire que les threads ne sautent que rarement
d'un processeur à un autre, ce qui est bon pour éviter les problèmes
d'invalidation de cache, etc. quand les threads sont commutés très
souvent et ne font que peu de calculs (typiquement un serveur web
multithreadé). Dans ton cas il faudrait au contraire demander que les
threads soient le plus étalés possibles si le système le permet.
Voir par exemple ceci pour Linux:
http://linux.die.net/man/2/sched_setaffinity
et ceci pour HP (et je crois idem pour Solaris)
http://docs.hp.com/en/B2355-60105/psrset.1M.html
Pour FreeBSD je crois qu'une telle chose a été ajoutée très récemment:
http://lists.freebsd.org/pipermail/cvs-src/2008-March/087965.html


--

Michel TALON
Thierry B.
Le #17920701
--{ JKB a plopé ceci: }--

question bête...
portable_ le PID maximal sur POSIX
rien trouvé de probant...



Moi non plus, mais est-ce vraiment important ?

~ $ cat oups.sh
#!/bin/ksh
echo $$
~ $ for i in 0 42 51 69
do
./oups.sh
done


26367
22142
15847
12039
~ $

Hein ?


--
"Please allow me to introduce myself
I'm a man of wealth and taste
I've used slrn for a long, long year
Stole many a G-Groper's faith"
Thierry B.
Le #17920691
--{ JKB a plopé ceci: }--

Tous les pids sont stockés au final dans des uint64 et je me demandais
bêtement si je pouvais brutalement utiliser les 32 bits de poids faibles
pour un pid (dans le cas d'un fork) et les 32 bits de poids forts pour



Baaaah, comment je trouve ça total gruik !

Pour moi, un pid, c'est un identifiant "opaque" qui ne supporte
que l'opérateur d'égalité. Aller au delà est risqué.

Pourquoi ne pas regrouper le pid et ta donnée privée dans une
petite struct à passer par les mécanismes gores du C de place
en place ?

--
Il donne pas tres envie son troll, je le trouve pretentieux et pedant,
mais dans un sens qui donne pas envie de repondre. On dirait un troll
snob. --{ ST, dans fcol.debats }--
JKB
Le #17922251
Le 21-11-2008, ? propos de
Re: PID max ?,
Thierry B. ?crivait dans fr.comp.os.unix :
--{ JKB a plopé ceci: }--

question bête...
portable_ le PID maximal sur POSIX
rien trouvé de probant...



Moi non plus, mais est-ce vraiment important ?



Oui. Est-ce que je t'ai déjà posé des questions bêtes ? ;-)

~ $ cat oups.sh
#!/bin/ksh
echo $$
~ $ for i in 0 42 51 69
do
./oups.sh
done


26367
22142
15847
12039
~ $

Hein ?



N'est-ce pas...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
JKB
Le #17922241
Le 21-11-2008, ? propos de
Re: PID max ?,
Thierry B. ?crivait dans fr.comp.os.unix :
--{ JKB a plopé ceci: }--

Tous les pids sont stockés au final dans des uint64 et je me demandais
bêtement si je pouvais brutalement utiliser les 32 bits de poids faibles
pour un pid (dans le cas d'un fork) et les 32 bits de poids forts pour



Baaaah, comment je trouve ça total gruik !

Pour moi, un pid, c'est un identifiant "opaque" qui ne supporte
que l'opérateur d'égalité. Aller au delà est risqué.

Pourquoi ne pas regrouper le pid et ta donnée privée dans une
petite struct à passer par les mécanismes gores du C de place
en place ?



Parce que je suis en train de modifier un programme écrit avec des
fork() en truc utilisant pthread_create() pour des histoires de gestion
de la mémoire. Mais il reste deux interrogations :
1/ est-ce que la valeur renvoyée par pthread_self() est unique sur un
système (et non sur un processus physique). Rien vu dans la doc à ce
sujet...
2/ il me faut les _deux_ informations, parce que je n'ai rien vu qui
ressemble à waitpid() pour les threads.

Sans compter que j'ai des tas de trucs à modifier dans le code s'il
m'est impossible de mapper les TID's dans un truc de 64 bits. D'un autre
côté, c'est ce qui me reste à faire... Enfin, c'est au moins plus simple
que la gestion de variables globales prenant des valeurs différentes
dans chaque thread et qui ne peuvent être définies par
pthread_key_create().

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Nicolas George
Le #17923721
JKB wrote in message
1/ est-ce que la valeur renvoyée par pthread_self() est unique sur un
système (et non sur un processus physique). Rien vu dans la doc à ce
sujet...



Aucune garantie. Un pthread_t pourrait très bien être un pointeur, pour ce
qu'on en sait.

2/ il me faut les _deux_ informations, parce que je n'ai rien vu qui
ressemble à waitpid() pour les threads.



Tu veux parler de pthread_join, ou autre chose ?

Sans compter que j'ai des tas de trucs à modifier dans le code s'il
m'est impossible de mapper les TID's dans un truc de 64 bits.



Eh bien bon courage.
JKB
Le #17924481
Le 22-11-2008, ? propos de
Re: PID max ?,
Nicolas George ?crivait dans fr.comp.os.unix :
JKB wrote in message
1/ est-ce que la valeur renvoyée par pthread_self() est unique sur un
système (et non sur un processus physique). Rien vu dans la doc à ce
sujet...



Aucune garantie. Un pthread_t pourrait très bien être un pointeur, pour ce
qu'on en sait.



getpid() renvoie un identifiant unique pour un processus.

pthread_self() renvoie un identifiant de thread. Je suppose comme il
existe pthread_kill() qu'on peut envoyer un signal à un thread et que
cela fonctionne comme kill() (en gros que je peux envoyer un signal
depuis un processus à un thread d'un autre processus pour peu que j'en
aie les droits). Il faut donc que cet identifiant soit unique. Le
problème est que je n'ai jamais vu cette information null part.

getpid()
getpid() returns the process ID of the calling process. The ID is guar-
anteed to be unique and is useful for constructing temporary file names.

pthread_self()
The pthread_self() function returns the thread ID of the calling thread.

-> aucune mention d'unicité

Sur HP-UX (10.20), j'ai obtenu :
pthread_self() returns the thread ID of the calling thread. The thread
ID returned is the same ID that is returned in the thread parameter to
the creating thread at thread creation time. Thread IDs are guaranteed
to be unique only within a process.

Conséquence : peut-on envoyer un signal d'un thread à un autre dès
que les deux threads tournent sur deux processus _différents_ ? Sinon,
comment faire ?

2/ il me faut les _deux_ informations, parce que je n'ai rien vu qui
ressemble à waitpid() pour les threads.



Tu veux parler de pthread_join, ou autre chose ?



Non, je parle de waitpid() avec l'option NOHANG et non d'un
pthread_join().

Sans compter que j'ai des tas de trucs à modifier dans le code s'il
m'est impossible de mapper les TID's dans un truc de 64 bits.



Eh bien bon courage.



Merci.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Nicolas George
Le #17924711
JKB wrote in message
Je suppose comme il
existe pthread_kill() qu'on peut envoyer un signal à un thread et que
cela fonctionne comme kill() (en gros que je peux envoyer un signal
depuis un processus à un thread d'un autre processus pour peu que j'en
aie les droits).



Lire la norme, ça peut aider, de temps en temps :

The pthread_kill() function provides a mechanism for asynchronously
directing a signal at a thread in the calling process.

J'attire ton attention sur les quatre derniers mots.
Publicité
Poster une réponse
Anonyme