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.
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
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.
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 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.
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.
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
JKB wrote:
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
JKB <knatschke@koenigsberg.fr> wrote:
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
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.
--{ 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"
--{ 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 ?
tth@puce ~ $ cat oups.sh
#!/bin/ksh
echo $$
tth@puce ~ $ for i in 0 42 51 69
do
./oups.sh
done
26367
22142
15847
12039
tth@puce ~ $
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"
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.
--{ 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 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 }--
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 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.
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 ? ;-)
tth@puce ~ $ cat oups.sh
#!/bin/ksh
echo $$
tth@puce ~ $ for i in 0 42 51 69
do
./oups.sh
done
26367
22142
15847
12039
tth@puce ~ $
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.
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 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.
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.
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
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 wrote in message <slrngifh0m.dgl.knatschke@rayleigh.systella.fr>:
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.
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 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.
Le 22-11-2008, ? propos de
Re: PID max ?,
Nicolas George ?crivait dans fr.comp.os.unix :
JKB wrote in message <slrngifh0m.dgl.knatschke@rayleigh.systella.fr>:
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.
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
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.
JKB wrote in message <slrngig217.dgl.knatschke@rayleigh.systella.fr>:
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.
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.
