En revoyant certains bouts de codes dans quelques programmes, je me suis
souvenu des milliards de warnings levés dans tout autant de milliards de
livres et articles parlant de programmation en C (et plus spécifiquement
UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui
fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas
avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DINH Viêt Hoà
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ?
La norme C ne connaît pas les threads.
Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Cela demanderait de définir une sémantique par rapport aux threads (un contexte par thread ou pas ?). Si on choisit de mettre un contexte par thread, cela prendrait évidemment plus de mémoire. Si on choisit de mettre un contexte partagé, je pense qu'on peut tomber sur des comportement imprévisibles (du fait de la schedulation des threads). Et cela demande de mettre un verrou, ce qui dégrade les performances.
D'ailleurs, je pense que pour régler tous ces problèmes, il existe va_copy(). Cela devrait largement suffire et on a une sémantique assez claire.
-- DINH V. Hoa,
"T'aurais pas une question sur le langage C ?" -- Emmanuel Delahaye
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui
fasse que les va_args ne soient pas thread-safe ?
La norme C ne connaît pas les threads.
Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec
un mécanisme réentrant ?
Cela demanderait de définir une sémantique par rapport aux threads (un
contexte par thread ou pas ?). Si on choisit de mettre un contexte par
thread, cela prendrait évidemment plus de mémoire.
Si on choisit de mettre un contexte partagé, je pense qu'on peut tomber
sur des comportement imprévisibles (du fait de la schedulation des
threads). Et cela demande de mettre un verrou, ce qui dégrade les
performances.
D'ailleurs, je pense que pour régler tous ces problèmes, il existe
va_copy(). Cela devrait largement suffire et on a une sémantique assez
claire.
--
DINH V. Hoa,
"T'aurais pas une question sur le langage C ?" -- Emmanuel Delahaye
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ?
La norme C ne connaît pas les threads.
Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Cela demanderait de définir une sémantique par rapport aux threads (un contexte par thread ou pas ?). Si on choisit de mettre un contexte par thread, cela prendrait évidemment plus de mémoire. Si on choisit de mettre un contexte partagé, je pense qu'on peut tomber sur des comportement imprévisibles (du fait de la schedulation des threads). Et cela demande de mettre un verrou, ce qui dégrade les performances.
D'ailleurs, je pense que pour régler tous ces problèmes, il existe va_copy(). Cela devrait largement suffire et on a une sémantique assez claire.
-- DINH V. Hoa,
"T'aurais pas une question sur le langage C ?" -- Emmanuel Delahaye
FAb
DINH Viêt Hoà writes:
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ?
La norme C ne connaît pas les threads.
Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Cela demanderait de définir une sémantique par rapport aux threads (un contexte par thread ou pas ?). Si on choisit de mettre un contexte par thread, cela prendrait évidemment plus de mémoire. Si on choisit de mettre un contexte partagé, je pense qu'on peut tomber sur des comportement imprévisibles (du fait de la schedulation des threads). Et cela demande de mettre un verrou, ce qui dégrade les performances.
D'ailleurs, je pense que pour régler tous ces problèmes, il existe va_copy(). Cela devrait largement suffire et on a une sémantique assez claire.
On peut faire le même reproche pour les tables de hachage... Par défaut y en a qu'une. Ça limite pas mal.
Fabrice.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui
fasse que les va_args ne soient pas thread-safe ?
La norme C ne connaît pas les threads.
Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec
un mécanisme réentrant ?
Cela demanderait de définir une sémantique par rapport aux threads (un
contexte par thread ou pas ?). Si on choisit de mettre un contexte par
thread, cela prendrait évidemment plus de mémoire.
Si on choisit de mettre un contexte partagé, je pense qu'on peut tomber
sur des comportement imprévisibles (du fait de la schedulation des
threads). Et cela demande de mettre un verrou, ce qui dégrade les
performances.
D'ailleurs, je pense que pour régler tous ces problèmes, il existe
va_copy(). Cela devrait largement suffire et on a une sémantique assez
claire.
On peut faire le même reproche pour les tables de hachage...
Par défaut y en a qu'une. Ça limite pas mal.
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ?
La norme C ne connaît pas les threads.
Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Cela demanderait de définir une sémantique par rapport aux threads (un contexte par thread ou pas ?). Si on choisit de mettre un contexte par thread, cela prendrait évidemment plus de mémoire. Si on choisit de mettre un contexte partagé, je pense qu'on peut tomber sur des comportement imprévisibles (du fait de la schedulation des threads). Et cela demande de mettre un verrou, ce qui dégrade les performances.
D'ailleurs, je pense que pour régler tous ces problèmes, il existe va_copy(). Cela devrait largement suffire et on a une sémantique assez claire.
On peut faire le même reproche pour les tables de hachage... Par défaut y en a qu'une. Ça limite pas mal.
Fabrice.
Laurent Coustet
Stephane Zuckerman wrote:
Bonjour,
Bonjour,
En revoyant certains bouts de codes dans quelques programmes, je me suis souvenu des milliards de warnings levés dans tout autant de milliards de livres et articles parlant de programmation en C (et plus spécifiquement UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Ah ben je suis fortement intéressé par la question aussi!
PS: sous OpenBSD vsnprint EST reentrante.
-- Laurent Coustet http://ed.zehome.com/
Stephane Zuckerman wrote:
Bonjour,
Bonjour,
En revoyant certains bouts de codes dans quelques programmes, je me suis
souvenu des milliards de warnings levés dans tout autant de milliards de
livres et articles parlant de programmation en C (et plus spécifiquement
UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui
fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas
avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Ah ben je suis fortement intéressé par la question aussi!
En revoyant certains bouts de codes dans quelques programmes, je me suis souvenu des milliards de warnings levés dans tout autant de milliards de livres et articles parlant de programmation en C (et plus spécifiquement UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
Ah ben je suis fortement intéressé par la question aussi!
PS: sous OpenBSD vsnprint EST reentrante.
-- Laurent Coustet http://ed.zehome.com/
Nicolas George
Stephane Zuckerman wrote in message :
En revoyant certains bouts de codes dans quelques programmes, je me suis souvenu des milliards de warnings levés dans tout autant de milliards de livres et articles parlant de programmation en C (et plus spécifiquement UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ?
Je n'ai jamais entendu parler de cette histoire. Tu as des références ? Et tu parles de quelle interface d'arguments variables : stdarg.h ou une interface plus ancienne ?
Stephane Zuckerman wrote in message
<Pine.OSF.4.58.0511011602360.4065@vega.utc.fr>:
En revoyant certains bouts de codes dans quelques programmes, je me suis
souvenu des milliards de warnings levés dans tout autant de milliards de
livres et articles parlant de programmation en C (et plus spécifiquement
UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui
fasse que les va_args ne soient pas thread-safe ?
Je n'ai jamais entendu parler de cette histoire. Tu as des références ? Et
tu parles de quelle interface d'arguments variables : stdarg.h ou une
interface plus ancienne ?
En revoyant certains bouts de codes dans quelques programmes, je me suis souvenu des milliards de warnings levés dans tout autant de milliards de livres et articles parlant de programmation en C (et plus spécifiquement UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ?
Je n'ai jamais entendu parler de cette histoire. Tu as des références ? Et tu parles de quelle interface d'arguments variables : stdarg.h ou une interface plus ancienne ?
Stephane Zuckerman
Je n'ai jamais entendu parler de cette histoire. Tu as des références ? Et tu parles de quelle interface d'arguments variables : stdarg.h ou une interface plus ancienne ?
Bon je viens de revérifier dans certains bouquins (dont le unix network programming au chapitre des threads), et effectivement "officiellement", le problème de réentrance ne devrait pas se poser avec les implémentations actuelles (donc pas stdarg.h). Maintenant, je suis certain d'être passé devant pas mal d'articles parlant de problèmes d'implémentation. Je vais re-chercher.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Je n'ai jamais entendu parler de cette histoire. Tu as des références ? Et
tu parles de quelle interface d'arguments variables : stdarg.h ou une
interface plus ancienne ?
Bon je viens de revérifier dans certains bouquins (dont le unix network
programming au chapitre des threads), et effectivement
"officiellement", le problème de réentrance ne devrait pas se poser avec
les implémentations actuelles (donc pas stdarg.h). Maintenant, je suis
certain d'être passé devant pas mal d'articles parlant de problèmes
d'implémentation. Je vais re-chercher.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Je n'ai jamais entendu parler de cette histoire. Tu as des références ? Et tu parles de quelle interface d'arguments variables : stdarg.h ou une interface plus ancienne ?
Bon je viens de revérifier dans certains bouquins (dont le unix network programming au chapitre des threads), et effectivement "officiellement", le problème de réentrance ne devrait pas se poser avec les implémentations actuelles (donc pas stdarg.h). Maintenant, je suis certain d'être passé devant pas mal d'articles parlant de problèmes d'implémentation. Je vais re-chercher.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Sylvain/11XX
Oui je vois une raison.
les parametres va_args donc tu parles sont ceux du main ? ou de n'importe quelle autre fonction ? aprceque la réponse est differente selon le cas.
SB
"Stephane Zuckerman" a écrit dans le message de news:
Bonjour,
En revoyant certains bouts de codes dans quelques programmes, je me suis souvenu des milliards de warnings levés dans tout autant de milliards de livres et articles parlant de programmation en C (et plus spécifiquement UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Oui je vois une raison.
les parametres va_args donc tu parles sont ceux du main ? ou de n'importe
quelle autre fonction ? aprceque la réponse est differente selon le cas.
SB
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0511011602360.4065@vega.utc.fr...
Bonjour,
En revoyant certains bouts de codes dans quelques programmes, je me suis
souvenu des milliards de warnings levés dans tout autant de milliards de
livres et articles parlant de programmation en C (et plus spécifiquement
UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui
fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas
avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
les parametres va_args donc tu parles sont ceux du main ? ou de n'importe quelle autre fonction ? aprceque la réponse est differente selon le cas.
SB
"Stephane Zuckerman" a écrit dans le message de news:
Bonjour,
En revoyant certains bouts de codes dans quelques programmes, je me suis souvenu des milliards de warnings levés dans tout autant de milliards de livres et articles parlant de programmation en C (et plus spécifiquement UNIX, d'où le follow-up).
Y a-t-il quelque part (dans la norme de C, ou ailleurs) une raison qui fasse que les va_args ne soient pas thread-safe ? Si non, pourquoi ne pas avoir réimplémenté les différentes libc avec un mécanisme réentrant ?
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
DINH Viêt Hoà
Oui je vois une raison.
les parametres va_args donc tu parles sont ceux du main ? ou de n'importe quelle autre fonction ? aprceque la réponse est differente selon le cas.
j'avoue que dans l'enchaînement du fil de discussion, je commence à de moins en moins comprendre ce que veux dire 'réentrant'. Le sens a l'air de varier d'une réponse à l'autre.
les parametres va_args donc tu parles sont ceux du main ? ou de n'importe
quelle autre fonction ? aprceque la réponse est differente selon le cas.
j'avoue que dans l'enchaînement du fil de discussion, je commence à de
moins en moins comprendre ce que veux dire 'réentrant'. Le sens a l'air
de varier d'une réponse à l'autre.
les parametres va_args donc tu parles sont ceux du main ? ou de n'importe quelle autre fonction ? aprceque la réponse est differente selon le cas.
j'avoue que dans l'enchaînement du fil de discussion, je commence à de moins en moins comprendre ce que veux dire 'réentrant'. Le sens a l'air de varier d'une réponse à l'autre.
