Omniprésence de l'x86 est-il une bonne chose pour Linux ?

Stephane CARPENTIER

02/10/2010 à 21:48

pehache-youplaboum a écrit:

"Stephane CARPENTIER" a écrit dans le mes sage
de news: 4ca70c7c$0$13217$

La réponse est quelques lignes plus haut.

En gros, tu considères que tous les programmeurs qui ne savent pas
bien programmer en multic?ur sont des cons ?

Ceux qui ont besoin de programmer en multicoeurs doivent apprendre à le
faire correctement,

C'est un peu utopique comme façon de voir.

Le mec, il est spécialisé en C et il doit être capable de savoir faire de la
programmation multicoeur si le besoin s'en fait sentir. Il n'a pas forc ément
le temps nécessaire pour une auto-formation correcte.

Et encore, là, je prends un spécialiste en C qui est disponible, ç a peut
être un spécialiste java qui sera disponible à un moment donné.

Miod Vallat

02/10/2010 à 22:02

Et encore, là, je prends un spécialiste en C qui est disponible, ça peut
être un spécialiste java qui sera disponible à un moment donné.

Ça existe, des spécialistes Java ???

JKB

02/10/2010 à 22:41

Le Sat, 2 Oct 2010 20:02:44 +0000 (UTC),
Miod Vallat écrivait :

Et encore, là, je prends un spécialiste en C qui est disponible, ça peut
être un spécialiste java qui sera disponible à un moment donné.

Ça existe, des spécialistes Java ???

Malheureusement ;-)

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB

02/10/2010 à 22:45

Le Sat, 02 Oct 2010 21:48:40 +0200,
Stephane CARPENTIER écrivait :

pehache-youplaboum a écrit:

"Stephane CARPENTIER" a écrit dans le message
de news: 4ca70c7c$0$13217$

La réponse est quelques lignes plus haut.

En gros, tu considères que tous les programmeurs qui ne savent pas
bien programmer en multic?ur sont des cons ?

Ceux qui ont besoin de programmer en multicoeurs doivent apprendre à le
faire correctement,

C'est un peu utopique comme façon de voir.

Le mec, il est spécialisé en C et il doit être capable de savoir faire de la
programmation multicoeur si le besoin s'en fait sentir. Il n'a pas forcément
le temps nécessaire pour une auto-formation correcte.

C'est bien là tout le problème. Et c'est pour cela qu'on voit des
API aberrantes arriver. Et ce n'est pas récent :

http://blogs.intellique.com/cgi-bin/tech/2010/09/30#worseisbetter

Et comme Linux cristalise un tas de développeurs pas forcément au
fait de la chose, on se tape des trucs ignobles parfaitement non
portables au détriment d'API correctes, portables et parfaitement
spécifiées.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

PP

02/10/2010 à 22:55

Le 02/10/2010 20:56, pehache-youplaboum a écrit :

Moi je parlais d'OpenMP et tu réponds sur un truc qui n'a strictement
rien à
voir, donc.

Et moi je ne parlais que de l'x86 et ses concurrents !
Est-ce bien pour Linux, finalement ?

...qui sont
peu voire non décrite (d'après un truc que j'ai lu il y a quelques
jours sur le net). Je trouve cela vachement interessant le concept !!
Soit c'est faux, soit c'est vrai et c'est plus grave, car qui utilise
alors ces fonctions/instructions ?
Je ne parle pas de compilation, je parle des processeurs eux-même !

Je ne vois pas bien l'intérêt qu'aurait Intel à ne pas décrire certaines
fonctions de ses processeurs.

Ben justement c'est ben pour cela que cela me chiffone

Stephane CARPENTIER

03/10/2010 à 01:20

Miod Vallat a écrit:

Et encore, là, je prends un spécialiste en C qui est disponible, ça peut
être un spécialiste java qui sera disponible à un moment donné .

Ça existe, des spécialistes Java ???

Tu sais, il existe des spécialistes en tout(*). Dès que tu as progr ammé dans
un langage pendant plus de deux mois tu deviens spécialiste.

(*) il paraît même qu'il y a des spécialistes en préhistoire qu i ont corrigé
toutes les erreurs du film << AO, le dernier Neandertal >> (désolé, je n'ai
pas pu m'en empêcher).

Stephane CARPENTIER

03/10/2010 à 01:23

JKB a écrit:

Le Sat, 02 Oct 2010 21:48:40 +0200,
Stephane CARPENTIER écrivait :
pehache-youplaboum a écrit:

"Stephane CARPENTIER" a écrit dans le m essage
de news: 4ca70c7c$0$13217$

La réponse est quelques lignes plus haut.

En gros, tu considères que tous les programmeurs qui ne savent p as
bien programmer en multic?ur sont des cons ?

Ceux qui ont besoin de programmer en multicoeurs doivent apprendre à le
faire correctement,

C'est un peu utopique comme façon de voir.

Le mec, il est spécialisé en C et il doit être capable de savo ir faire de
la programmation multicoeur si le besoin s'en fait sentir. Il n'a pa s
forcément le temps nécessaire pour une auto-formation correcte.

C'est bien là tout le problème. Et c'est pour cela qu'on voit des
API aberrantes arriver. Et ce n'est pas récent :

http://blogs.intellique.com/cgi-bin/tech/2010/09/30#worseisbetter

Et comme Linux cristalise un tas de développeurs pas forcément au
fait de la chose,

C'est pas spécialement Linux, c'est partout pareil en informatique. I l y a
plus de travail que de personnes et il faut que ça coûte le moins c her
possible.

Du coup, les gens sont réaffectés d'un endroit à un autre assez r apidedment.

Nicolas George

03/10/2010 à 01:44

JKB , dans le message , a
écrit :

Je ne sais pas ce que tu utilises comme système, mais sur tous les
miens malloc() est thread safe. Et des mallocs dans les
gestionnaires de signaux, j'en fais.

Tu confonds allègrement thread-safe et async-signal-safe. Single Unix
stipule que malloc est le premier, pas le second.

La preuve est faite, tu es un guignol qui se prend pour un dieu de la
programmation quand il en ignore les bases. J'explicite l'exemple présent
pour ceux qui auraient eu le courage de nous lire jusqu'ici, parce qu'il
montre à quel point tu es à côté de la plaque, et j'arrête là.

Une fonction est thread-safe si elle peut être appelée depuis deux threads
sans faire d'efforts particuliers de synchronisation. Ça arrive si elle ne
touche que des données locales ou passées en argument, ou si elle fait
elle-même les efforts de synchronisation. malloc est effectivement
thread-safe, d'après les normes ; il peut l'être efficacement par l'usage
d'informations en thread-local-storage.

Une fonction est async-signal-safe si elle peut être appelée, sans efforts
de synchronisation, depuis un gestionnaire de signal. Assurer cette
caractéristique pour une fonction qui manipule un état global est nettement
plus difficile, parce qu'il n'y a pas de notion de « signal-local-storage ».
La seule solution serait que chaque appel masque tous les signaux pendant
son exécution, ce qui requiert un appel système. Terriblement inefficace.

Pour cette raison, la plupart des fonctions de la libc doivent, d'après le
standard, être thread-safe, mais la liste des fonctions qui doivent être
async-signal-safe est nettement plus courte. On la trouve ici :
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
(il faut descendre un peu pour avoir la liste). On y a trouve exit, fork,
write et quelques autres, mais pas malloc, ce qui est logique, puisque
malloc est l'archétype des fonctions qui manipulent un état global et ont
besoin d'une efficacité maximale.

Je me souviens que tu t'es naguère plaint de segfaults mystérieuses dans un
programme. Tu fais des mallocs dans des signal handlers : pas la peine de
chercher plus loin.

JKB , dans le message <slrniaes4b.glp.jkb@rayleigh.systella.fr>, a
écrit :

Je ne sais pas ce que tu utilises comme système, mais sur tous les
miens malloc() est thread safe. Et des mallocs dans les
gestionnaires de signaux, j'en fais.

Tu confonds allègrement thread-safe et async-signal-safe. Single Unix
stipule que malloc est le premier, pas le second.

La preuve est faite, tu es un guignol qui se prend pour un dieu de la
programmation quand il en ignore les bases. J'explicite l'exemple présent
pour ceux qui auraient eu le courage de nous lire jusqu'ici, parce qu'il
montre à quel point tu es à côté de la plaque, et j'arrête là.

Une fonction est thread-safe si elle peut être appelée depuis deux threads
sans faire d'efforts particuliers de synchronisation. Ça arrive si elle ne
touche que des données locales ou passées en argument, ou si elle fait
elle-même les efforts de synchronisation. malloc est effectivement
thread-safe, d'après les normes ; il peut l'être efficacement par l'usage
d'informations en thread-local-storage.

Une fonction est async-signal-safe si elle peut être appelée, sans efforts
de synchronisation, depuis un gestionnaire de signal. Assurer cette
caractéristique pour une fonction qui manipule un état global est nettement
plus difficile, parce qu'il n'y a pas de notion de « signal-local-storage ».
La seule solution serait que chaque appel masque tous les signaux pendant
son exécution, ce qui requiert un appel système. Terriblement inefficace.

Pour cette raison, la plupart des fonctions de la libc doivent, d'après le
standard, être thread-safe, mais la liste des fonctions qui doivent être
async-signal-safe est nettement plus courte. On la trouve ici :
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
(il faut descendre un peu pour avoir la liste). On y a trouve exit, fork,
write et quelques autres, mais pas malloc, ce qui est logique, puisque
malloc est l'archétype des fonctions qui manipulent un état global et ont
besoin d'une efficacité maximale.

Je me souviens que tu t'es naguère plaint de segfaults mystérieuses dans un
programme. Tu fais des mallocs dans des signal handlers : pas la peine de
chercher plus loin.

Vous avez filtré cet utilisateur ! Consultez son message

JKB , dans le message , a
écrit :

Je ne sais pas ce que tu utilises comme système, mais sur tous les
miens malloc() est thread safe. Et des mallocs dans les
gestionnaires de signaux, j'en fais.

Tu confonds allègrement thread-safe et async-signal-safe. Single Unix
stipule que malloc est le premier, pas le second.

La preuve est faite, tu es un guignol qui se prend pour un dieu de la
programmation quand il en ignore les bases. J'explicite l'exemple présent
pour ceux qui auraient eu le courage de nous lire jusqu'ici, parce qu'il
montre à quel point tu es à côté de la plaque, et j'arrête là.

Une fonction est thread-safe si elle peut être appelée depuis deux threads
sans faire d'efforts particuliers de synchronisation. Ça arrive si elle ne
touche que des données locales ou passées en argument, ou si elle fait
elle-même les efforts de synchronisation. malloc est effectivement
thread-safe, d'après les normes ; il peut l'être efficacement par l'usage
d'informations en thread-local-storage.

Une fonction est async-signal-safe si elle peut être appelée, sans efforts
de synchronisation, depuis un gestionnaire de signal. Assurer cette
caractéristique pour une fonction qui manipule un état global est nettement
plus difficile, parce qu'il n'y a pas de notion de « signal-local-storage ».
La seule solution serait que chaque appel masque tous les signaux pendant
son exécution, ce qui requiert un appel système. Terriblement inefficace.

Pour cette raison, la plupart des fonctions de la libc doivent, d'après le
standard, être thread-safe, mais la liste des fonctions qui doivent être
async-signal-safe est nettement plus courte. On la trouve ici :
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
(il faut descendre un peu pour avoir la liste). On y a trouve exit, fork,
write et quelques autres, mais pas malloc, ce qui est logique, puisque
malloc est l'archétype des fonctions qui manipulent un état global et ont
besoin d'une efficacité maximale.

Je me souviens que tu t'es naguère plaint de segfaults mystérieuses dans un
programme. Tu fais des mallocs dans des signal handlers : pas la peine de
chercher plus loin.

JKB

03/10/2010 à 10:35

Le 02 Oct 2010 23:44:53 GMT,
Nicolas George <nicolas$ écrivait :

JKB , dans le message , a
écrit :
Je ne sais pas ce que tu utilises comme système, mais sur tous les
miens malloc() est thread safe. Et des mallocs dans les
gestionnaires de signaux, j'en fais.

Tu confonds allègrement thread-safe et async-signal-safe. Single Unix
stipule que malloc est le premier, pas le second.

Tu as zappé une partie du problème. Évite de couper comme un goret
pour avoir l'impression d'avoir raison.

Tu peux parfaitement appeler un malloc() depuis un gestionnaire de
signal quand tu _sais_ ce que tu fais. Il suffit pour cela qu'il
soit thread safe. Le fait d'être async signal safe t'indique
simplement que tu peux l'utiliser n'importe comment. Après, si tu
codes comme un imbécile, il vaut effectivement pour toi ne pas appeler
un malloc() depuis un processus asynchrone. De toute façon, celui de
la glibc t'explosera à la figure (enfin non, bloquera), donc le problème
ne se pose pas !

Et si ton niveau de programmation est celui-là, effectivement, je te
déconseille l'utilisation des signaux. Tu ne pourras que te tirer
une balle dans le pied.

La preuve est faite, tu es un guignol qui se prend pour un dieu de la
programmation quand il en ignore les bases. J'explicite l'exemple présent
pour ceux qui auraient eu le courage de nous lire jusqu'ici, parce qu'il
montre à quel point tu es à côté de la plaque, et j'arrête là.

Naturellement, je te rappelle que j'attends encore que ta grandeur
m'explique comment dans l'exemple que je t'ai donné, tu remplace
efficacement un signal par un truc synchrone.

Et le branque à côté de la plaque, il a modestement participé à un truc
qui s'appelle WASD, et qui ne fonctionne que comme ça (et très bien
puisque ça éclate apache). Regarde un peu les sources si tu en as le
courage. Ça ne fonctionne _que_ par interruptions (et ça ne peut que
tourner sous OpenVMS, parce que sous Unix, ce genre de programation
est impossible).

Une fonction est thread-safe si elle peut être appelée depuis deux threads
sans faire d'efforts particuliers de synchronisation. Ça arrive si elle ne
touche que des données locales ou passées en argument, ou si elle fait
elle-même les efforts de synchronisation. malloc est effectivement
thread-safe, d'après les normes ; il peut l'être efficacement par l'usage
d'informations en thread-local-storage.

Une fonction est async-signal-safe si elle peut être appelée, sans efforts
de synchronisation, depuis un gestionnaire de signal. Assurer cette
caractéristique pour une fonction qui manipule un état global est nettement
plus difficile, parce qu'il n'y a pas de notion de « signal-local-storage ».
La seule solution serait que chaque appel masque tous les signaux pendant
son exécution, ce qui requiert un appel système. Terriblement inefficace.

Tu viens juste de prouver que tu connais deux définitions,
absolument pas que tu sais utiliser les gestionnaires de signaux. Il
y a beaucoup plus efficace qu'un masque de signaux (surtout si tes
signaux ne sont pas RT et que tu veux éviter d'en perdre). Je te laisse
chercher. Ne compte surtout pas sur moi pour te donner une piste, du
haut de ta grandeur, tout ce que je pourrais te donner sera qualifié
de merde.

Je te rappelle simplement que contrairement à toi, je n'ai jamais
qualifié tes productions (pour peu que tu en aies eu) de merdes. Mon
propos est juste de te dire que tu te fourvoies en prétendant qu'un
mécanisme synchrone est équivalent à un asynchrone. Tout ce
que tu trouves à répondre est que je suis un con (peut-être) et que
je ne sais pas coder (ça reste à prouver). De ta part, dire que je
ne sais pas coder quelque chose, ou que les gens qui codent avec
moi parce que ça revient à la même chose, sont des branques, c'est
tout de même l'hôpital qui se fout de la charité.

Pour cette raison, la plupart des fonctions de la libc doivent, d'après le
standard, être thread-safe, mais la liste des fonctions qui doivent être
async-signal-safe est nettement plus courte. On la trouve ici :
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
(il faut descendre un peu pour avoir la liste). On y a trouve exit, fork,
write et quelques autres, mais pas malloc, ce qui est logique, puisque
malloc est l'archétype des fonctions qui manipulent un état global et ont
besoin d'une efficacité maximale.

La raison n'est pas celle-là. Là encore, cherche, parce que tout ce
que je pourrais te dire sera systématiquement dénigré.

Je me souviens que tu t'es naguère plaint de segfaults mystérieuses dans un
programme. Tu fais des mallocs dans des signal handlers : pas la peine de
chercher plus loin.

Sauf que comme à ton habitude tu oublies les conclusions. Ce problème
qui d'après toi venait d'un malloc() dans un gestionnaire de signal
ne venait pas de là puisque dans le programme en question, il n'y en
avait _pas_. Dommage pour toi ! Ce problème venait d'un bug de ld qui
se mélangeait les pinceaux entre un allocateur spécifique et le
malloc() du système.

Tu peux sortir d'autres questions prétendûment à la con que je suis
allé poser sur fclc ou fcou et concernant des points spécifiques sur les
programmations concurrentes, je t'attends même de pied ferme. Aucun
de ces problèmes ne venait d'un malloc() dans un gestionnaire de
signal. Ce n'est pas parce qu'un malloc() ou un free() explose en
vol que le problème vient forcément de ces deux fonctions. Mais
comme à ton habitude, tu juges sans même essayer de comprendre d'où
peut venir le problème. C'est tellement rassurant !...

Par ailleurs, lorsque je prends la peine de poser une question,
c'est sur un point très précis après avoir lu, relu les specs et
après avoir tourné le code dans tous les sens pas mal de temps.

Tout le monde ne peut pas en dire autant.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 02 Oct 2010 23:44:53 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :

JKB , dans le message <slrniaes4b.glp.jkb@rayleigh.systella.fr>, a
écrit :

Je ne sais pas ce que tu utilises comme système, mais sur tous les
miens malloc() est thread safe. Et des mallocs dans les
gestionnaires de signaux, j'en fais.

Tu confonds allègrement thread-safe et async-signal-safe. Single Unix
stipule que malloc est le premier, pas le second.

Tu as zappé une partie du problème. Évite de couper comme un goret
pour avoir l'impression d'avoir raison.

Tu peux parfaitement appeler un malloc() depuis un gestionnaire de
signal quand tu _sais_ ce que tu fais. Il suffit pour cela qu'il
soit thread safe. Le fait d'être async signal safe t'indique
simplement que tu peux l'utiliser n'importe comment. Après, si tu
codes comme un imbécile, il vaut effectivement pour toi ne pas appeler
un malloc() depuis un processus asynchrone. De toute façon, celui de
la glibc t'explosera à la figure (enfin non, bloquera), donc le problème
ne se pose pas !

Et si ton niveau de programmation est celui-là, effectivement, je te
déconseille l'utilisation des signaux. Tu ne pourras que te tirer
une balle dans le pied.

La preuve est faite, tu es un guignol qui se prend pour un dieu de la
programmation quand il en ignore les bases. J'explicite l'exemple présent
pour ceux qui auraient eu le courage de nous lire jusqu'ici, parce qu'il
montre à quel point tu es à côté de la plaque, et j'arrête là.

Naturellement, je te rappelle que j'attends encore que ta grandeur
m'explique comment dans l'exemple que je t'ai donné, tu remplace
efficacement un signal par un truc synchrone.

Et le branque à côté de la plaque, il a modestement participé à un truc
qui s'appelle WASD, et qui ne fonctionne que comme ça (et très bien
puisque ça éclate apache). Regarde un peu les sources si tu en as le
courage. Ça ne fonctionne _que_ par interruptions (et ça ne peut que
tourner sous OpenVMS, parce que sous Unix, ce genre de programation
est impossible).

Une fonction est thread-safe si elle peut être appelée depuis deux threads
sans faire d'efforts particuliers de synchronisation. Ça arrive si elle ne
touche que des données locales ou passées en argument, ou si elle fait
elle-même les efforts de synchronisation. malloc est effectivement
thread-safe, d'après les normes ; il peut l'être efficacement par l'usage
d'informations en thread-local-storage.

Une fonction est async-signal-safe si elle peut être appelée, sans efforts
de synchronisation, depuis un gestionnaire de signal. Assurer cette
caractéristique pour une fonction qui manipule un état global est nettement
plus difficile, parce qu'il n'y a pas de notion de « signal-local-storage ».
La seule solution serait que chaque appel masque tous les signaux pendant
son exécution, ce qui requiert un appel système. Terriblement inefficace.

Tu viens juste de prouver que tu connais deux définitions,
absolument pas que tu sais utiliser les gestionnaires de signaux. Il
y a beaucoup plus efficace qu'un masque de signaux (surtout si tes
signaux ne sont pas RT et que tu veux éviter d'en perdre). Je te laisse
chercher. Ne compte surtout pas sur moi pour te donner une piste, du
haut de ta grandeur, tout ce que je pourrais te donner sera qualifié
de merde.

Je te rappelle simplement que contrairement à toi, je n'ai jamais
qualifié tes productions (pour peu que tu en aies eu) de merdes. Mon
propos est juste de te dire que tu te fourvoies en prétendant qu'un
mécanisme synchrone est équivalent à un asynchrone. Tout ce
que tu trouves à répondre est que je suis un con (peut-être) et que
je ne sais pas coder (ça reste à prouver). De ta part, dire que je
ne sais pas coder quelque chose, ou que les gens qui codent avec
moi parce que ça revient à la même chose, sont des branques, c'est
tout de même l'hôpital qui se fout de la charité.

Pour cette raison, la plupart des fonctions de la libc doivent, d'après le
standard, être thread-safe, mais la liste des fonctions qui doivent être
async-signal-safe est nettement plus courte. On la trouve ici :
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
(il faut descendre un peu pour avoir la liste). On y a trouve exit, fork,
write et quelques autres, mais pas malloc, ce qui est logique, puisque
malloc est l'archétype des fonctions qui manipulent un état global et ont
besoin d'une efficacité maximale.

La raison n'est pas celle-là. Là encore, cherche, parce que tout ce
que je pourrais te dire sera systématiquement dénigré.

Je me souviens que tu t'es naguère plaint de segfaults mystérieuses dans un
programme. Tu fais des mallocs dans des signal handlers : pas la peine de
chercher plus loin.

Sauf que comme à ton habitude tu oublies les conclusions. Ce problème
qui d'après toi venait d'un malloc() dans un gestionnaire de signal
ne venait pas de là puisque dans le programme en question, il n'y en
avait _pas_. Dommage pour toi ! Ce problème venait d'un bug de ld qui
se mélangeait les pinceaux entre un allocateur spécifique et le
malloc() du système.

Tu peux sortir d'autres questions prétendûment à la con que je suis
allé poser sur fclc ou fcou et concernant des points spécifiques sur les
programmations concurrentes, je t'attends même de pied ferme. Aucun
de ces problèmes ne venait d'un malloc() dans un gestionnaire de
signal. Ce n'est pas parce qu'un malloc() ou un free() explose en
vol que le problème vient forcément de ces deux fonctions. Mais
comme à ton habitude, tu juges sans même essayer de comprendre d'où
peut venir le problème. C'est tellement rassurant !...

Par ailleurs, lorsque je prends la peine de poser une question,
c'est sur un point très précis après avoir lu, relu les specs et
après avoir tourné le code dans tous les sens pas mal de temps.

Tout le monde ne peut pas en dire autant.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le 02 Oct 2010 23:44:53 GMT,
Nicolas George <nicolas$ écrivait :

JKB , dans le message , a
écrit :
Je ne sais pas ce que tu utilises comme système, mais sur tous les
miens malloc() est thread safe. Et des mallocs dans les
gestionnaires de signaux, j'en fais.

Tu confonds allègrement thread-safe et async-signal-safe. Single Unix
stipule que malloc est le premier, pas le second.

Tu as zappé une partie du problème. Évite de couper comme un goret
pour avoir l'impression d'avoir raison.

Tu peux parfaitement appeler un malloc() depuis un gestionnaire de
signal quand tu _sais_ ce que tu fais. Il suffit pour cela qu'il
soit thread safe. Le fait d'être async signal safe t'indique
simplement que tu peux l'utiliser n'importe comment. Après, si tu
codes comme un imbécile, il vaut effectivement pour toi ne pas appeler
un malloc() depuis un processus asynchrone. De toute façon, celui de
la glibc t'explosera à la figure (enfin non, bloquera), donc le problème
ne se pose pas !

Et si ton niveau de programmation est celui-là, effectivement, je te
déconseille l'utilisation des signaux. Tu ne pourras que te tirer
une balle dans le pied.

La preuve est faite, tu es un guignol qui se prend pour un dieu de la
programmation quand il en ignore les bases. J'explicite l'exemple présent
pour ceux qui auraient eu le courage de nous lire jusqu'ici, parce qu'il
montre à quel point tu es à côté de la plaque, et j'arrête là.

Naturellement, je te rappelle que j'attends encore que ta grandeur
m'explique comment dans l'exemple que je t'ai donné, tu remplace
efficacement un signal par un truc synchrone.

Et le branque à côté de la plaque, il a modestement participé à un truc
qui s'appelle WASD, et qui ne fonctionne que comme ça (et très bien
puisque ça éclate apache). Regarde un peu les sources si tu en as le
courage. Ça ne fonctionne _que_ par interruptions (et ça ne peut que
tourner sous OpenVMS, parce que sous Unix, ce genre de programation
est impossible).

Une fonction est thread-safe si elle peut être appelée depuis deux threads
sans faire d'efforts particuliers de synchronisation. Ça arrive si elle ne
touche que des données locales ou passées en argument, ou si elle fait
elle-même les efforts de synchronisation. malloc est effectivement
thread-safe, d'après les normes ; il peut l'être efficacement par l'usage
d'informations en thread-local-storage.

Une fonction est async-signal-safe si elle peut être appelée, sans efforts
de synchronisation, depuis un gestionnaire de signal. Assurer cette
caractéristique pour une fonction qui manipule un état global est nettement
plus difficile, parce qu'il n'y a pas de notion de « signal-local-storage ».
La seule solution serait que chaque appel masque tous les signaux pendant
son exécution, ce qui requiert un appel système. Terriblement inefficace.

Tu viens juste de prouver que tu connais deux définitions,
absolument pas que tu sais utiliser les gestionnaires de signaux. Il
y a beaucoup plus efficace qu'un masque de signaux (surtout si tes
signaux ne sont pas RT et que tu veux éviter d'en perdre). Je te laisse
chercher. Ne compte surtout pas sur moi pour te donner une piste, du
haut de ta grandeur, tout ce que je pourrais te donner sera qualifié
de merde.

Je te rappelle simplement que contrairement à toi, je n'ai jamais
qualifié tes productions (pour peu que tu en aies eu) de merdes. Mon
propos est juste de te dire que tu te fourvoies en prétendant qu'un
mécanisme synchrone est équivalent à un asynchrone. Tout ce
que tu trouves à répondre est que je suis un con (peut-être) et que
je ne sais pas coder (ça reste à prouver). De ta part, dire que je
ne sais pas coder quelque chose, ou que les gens qui codent avec
moi parce que ça revient à la même chose, sont des branques, c'est
tout de même l'hôpital qui se fout de la charité.

Pour cette raison, la plupart des fonctions de la libc doivent, d'après le
standard, être thread-safe, mais la liste des fonctions qui doivent être
async-signal-safe est nettement plus courte. On la trouve ici :
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
(il faut descendre un peu pour avoir la liste). On y a trouve exit, fork,
write et quelques autres, mais pas malloc, ce qui est logique, puisque
malloc est l'archétype des fonctions qui manipulent un état global et ont
besoin d'une efficacité maximale.

La raison n'est pas celle-là. Là encore, cherche, parce que tout ce
que je pourrais te dire sera systématiquement dénigré.

Je me souviens que tu t'es naguère plaint de segfaults mystérieuses dans un
programme. Tu fais des mallocs dans des signal handlers : pas la peine de
chercher plus loin.

Sauf que comme à ton habitude tu oublies les conclusions. Ce problème
qui d'après toi venait d'un malloc() dans un gestionnaire de signal
ne venait pas de là puisque dans le programme en question, il n'y en
avait _pas_. Dommage pour toi ! Ce problème venait d'un bug de ld qui
se mélangeait les pinceaux entre un allocateur spécifique et le
malloc() du système.

Tu peux sortir d'autres questions prétendûment à la con que je suis
allé poser sur fclc ou fcou et concernant des points spécifiques sur les
programmations concurrentes, je t'attends même de pied ferme. Aucun
de ces problèmes ne venait d'un malloc() dans un gestionnaire de
signal. Ce n'est pas parce qu'un malloc() ou un free() explose en
vol que le problème vient forcément de ces deux fonctions. Mais
comme à ton habitude, tu juges sans même essayer de comprendre d'où
peut venir le problème. C'est tellement rassurant !...

Par ailleurs, lorsque je prends la peine de poser une question,
c'est sur un point très précis après avoir lu, relu les specs et
après avoir tourné le code dans tous les sens pas mal de temps.

Tout le monde ne peut pas en dire autant.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Nicolas George

03/10/2010 à 11:00

JKB , dans le message , a
écrit :
<snip>

Tout un tas d'affirmations qui reposent sur la seule justification « je suis
trop fort », sans aucun point technique. Complètement caricatural de ta
production habituelle.

Omniprésence de l'x86 est-il une bonne chose pour Linux ?

10 réponses

Veuillez sélectionner un problème