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 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 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 ?
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.
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.
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.
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...).
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...).
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...).
question bête...
portable_ le PID maximal sur POSIX
rien trouvé de probant...
do
./oups.sh
done
question bête...
portable_ le PID maximal sur POSIX
rien trouvé de probant...
do
./oups.sh
done
question bête...
portable_ le PID maximal sur POSIX
rien trouvé de probant...
do
./oups.sh
done
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
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
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
--{ 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 69do
./oups.sh
done
26367
22142
15847
12039
~ $
Hein ?
--{ 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 ?
--{ 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 69do
./oups.sh
done
26367
22142
15847
12039
~ $
Hein ?
--{ 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 ?
--{ 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 ?
--{ 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 ?
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.
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.
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.
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.
Eh bien bon courage.
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.
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).
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).
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).