Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Linux, Solaris, xBSD... POSIX ?

3 réponses
Avatar
JKB
Bonjour à tous,

Je viens de passer quelques heures à débuguer un programme de calcul
qui tourne parfaitement sous FreeBSD et Linux, mais qui plantait
lamentablement sous Solaris (mouture 10), jusqu'à ce que je
comprenne d'où vient le problème.

J'ai un processus de calcul qui peut sous certaines conditions faire
un fork() de lui-même. Ce processus utilise une bibliothèque
partagée (un wrapper un peu spécial d'une partie de BOOST).
Comme je suis poli, j'ouvre cette bibliothèque avec dlopen() et je
la ferme avec dlclose().

Sous Linux, le fork() semble copier le descripteur de bibliothèque
si bien qu'on peut fermer celle-ci dans le fils et elle reste
accessible au père. Sous FreeBSD, cela semble fonctionner de la même
façon. Sous Solaris, patatras, le simple fait de fermer la
bibliothèque dans un quelconque fils la ferme aussi dans le père !

1/ Quel est le comportement standard ? Solaris ou Linux ?

2/ Y a-t-il moyen d'éviter cela ?

3/ Quid des descripteurs de fichiers ? Je suppose que si un
processus fils ferme un fichier, il sera aussi fermé pour le père
(je n'ai pas testé)...

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.

3 réponses

Avatar
JKB
Le 01-10-2008, ? propos de
Linux, Solaris, xBSD... POSIX ?,
JKB ?crivait dans fr.comp.os.unix :
Bonjour à tous,

Je viens de passer quelques heures à débuguer un programme de calcul
qui tourne parfaitement sous FreeBSD et Linux, mais qui plantait
lamentablement sous Solaris (mouture 10), jusqu'à ce que je
comprenne d'où vient le problème.

J'ai un processus de calcul qui peut sous certaines conditions faire
un fork() de lui-même. Ce processus utilise une bibliothèque
partagée (un wrapper un peu spécial d'une partie de BOOST).
Comme je suis poli, j'ouvre cette bibliothèque avec dlopen() et je
la ferme avec dlclose().

Sous Linux, le fork() semble copier le descripteur de bibliothèque
si bien qu'on peut fermer celle-ci dans le fils et elle reste
accessible au père. Sous FreeBSD, cela semble fonctionner de la même
façon. Sous Solaris, patatras, le simple fait de fermer la
bibliothèque dans un quelconque fils la ferme aussi dans le père !

1/ Quel est le comportement standard ? Solaris ou Linux ?

2/ Y a-t-il moyen d'éviter cela ?

3/ Quid des descripteurs de fichiers ? Je suppose que si un
processus fils ferme un fichier, il sera aussi fermé pour le père
(je n'ai pas testé)...



Bon, problème ailleurs... Sous Solaris, dlsym() ne réinitialise pas
les erreurs renvoyées par dlerror() contrairement aux versions Linux
et FreeBSD.

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.
Avatar
Marc Boyer
On 2008-10-01, JKB wrote:
Bonjour à tous,

Je viens de passer quelques heures à débuguer un programme de calcul
qui tourne parfaitement sous FreeBSD et Linux, mais qui plantait
lamentablement sous Solaris (mouture 10), jusqu'à ce que je
comprenne d'où vient le problème.

J'ai un processus de calcul qui peut sous certaines conditions faire
un fork() de lui-même. Ce processus utilise une bibliothèque
partagée (un wrapper un peu spécial d'une partie de BOOST).
Comme je suis poli, j'ouvre cette bibliothèque avec dlopen() et je
la ferme avec dlclose().

Sous Linux, le fork() semble copier le descripteur de bibliothèque
si bien qu'on peut fermer celle-ci dans le fils et elle reste
accessible au père. Sous FreeBSD, cela semble fonctionner de la même
façon. Sous Solaris, patatras, le simple fait de fermer la
bibliothèque dans un quelconque fils la ferme aussi dans le père !

1/ Quel est le comportement standard ? Solaris ou Linux ?



Je ne suis pas expert sur ces points de détail. Mon expérience, c'est
que Solaris avait plutôt tendance à respecter la norme et Linux à faciliter
la vie du développeur.

Un petit coup de Google permet d'avoir les pages man POSIX semble-t-il:
http://www.opengroup.org/onlinepubs/000095399/functions/dlopen.html
http://www.opengroup.org/onlinepubs/000095399/functions/fork.html


Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
JKB
Le 02-10-2008, ? propos de
Re: Linux, Solaris, xBSD... POSIX ?,
Marc Boyer ?crivait dans fr.comp.os.unix :
On 2008-10-01, JKB wrote:
Bonjour à tous,

Je viens de passer quelques heures à débuguer un programme de calcul
qui tourne parfaitement sous FreeBSD et Linux, mais qui plantait
lamentablement sous Solaris (mouture 10), jusqu'à ce que je
comprenne d'où vient le problème.

J'ai un processus de calcul qui peut sous certaines conditions faire
un fork() de lui-même. Ce processus utilise une bibliothèque
partagée (un wrapper un peu spécial d'une partie de BOOST).
Comme je suis poli, j'ouvre cette bibliothèque avec dlopen() et je
la ferme avec dlclose().

Sous Linux, le fork() semble copier le descripteur de bibliothèque
si bien qu'on peut fermer celle-ci dans le fils et elle reste
accessible au père. Sous FreeBSD, cela semble fonctionner de la même
façon. Sous Solaris, patatras, le simple fait de fermer la
bibliothèque dans un quelconque fils la ferme aussi dans le père !

1/ Quel est le comportement standard ? Solaris ou Linux ?



Je ne suis pas expert sur ces points de détail. Mon expérience, c'est
que Solaris avait plutôt tendance à respecter la norme et Linux à faciliter
la vie du développeur.

Un petit coup de Google permet d'avoir les pages man POSIX semble-t-il:
http://www.opengroup.org/onlinepubs/000095399/functions/dlopen.html
http://www.opengroup.org/onlinepubs/000095399/functions/fork.html



Merci pour la réponse. Je viens de trouver le problème qui est un
truc sournois de non remise à jour d'un champs par dlsym(). Ce qui
est amusant, c'est que Solaris suit le man de Linux et Linux, celui
de Solaris :-P

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.