[Pthreads/Windows] Problème avec pthread_t

Version imprimable

Bonsoir,

Voilà un code qui illustre mon problème :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #include <stdio.h> #include <pthread.h> struct s { pthread_t id; void* (*pf) (void*); }; static void* f (void* p); int main (void) { struct s s1 = {0, f}; s1.pf(NULL); return 0; } static void* f (void* p) { (void)p; puts("test"); return NULL; }
GCC me dit :
Code:

1 2 3 4 5 6 forums.c: In function `main': forums.c:15: warning: missing braces around initializer forums.c:15: warning: (near initialization for `s1.id') forums.c:15: warning: initialization makes integer from pointer without a cast forums.c:15: warning: missing initializer forums.c:15: warning: (near initialization for `s1.pf')
Visual C 2005 :
Code:

1 2 forums.c(15) : warning C4047: 'initialisation'*: 'unsigned int' diffère de 'void *(__cdecl *)(void *)' dans les niveaux d'indirection
Et à l'exécution, ça plante. Si dans la structure s1 je remplace le champ pthread_t par un int, aucun problème (à la compilation et à l'exécution).
Les headers et la bibliothèque pthreads viennent du fichier "pthreads-w32-2-8-0-release.exe" téléchargé sur ce site : http://sourceware.org/pthreads-win32/.
Est-ce qu'il y a une erreur dans mon code ? J'avoue pour le moment ça m'échappe complètement. Je testerai sur une autre plateforme demain mais ça m'arrangerait de pouvoir utiliser les pthreads sous Windows aussi.

Merci.

Citation:

Envoyé par dapounet

Voilà un code qui illustre mon problème :

Ceci fonctionne (en C, évidemment) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
#include <stdio.h>
#include <pthread.h>
 
struct s
{
   pthread_t id;
   void *(*pf) (void *);
};
 
static void *f (void *p)
{
   (void) p;
 
   puts ("test");
 
   return NULL;
}
 
int main (void)
{
   struct s s1 = { {0, 0}, f };
 
   s1.pf (NULL);
 
   return 0;
}

Sous WIN32, pthread_t est défini ainsi :
Code:

1 2 3 4 5 6 7 typedef struct { void * p; /* Pointer to actual object */ unsigned int x; /* Extra information - reuse count etc */ } ptw32_handle_t; typedef ptw32_handle_t pthread_t;
Je conseille d'utiliser une des nouveautés du C99 (puisque tu utilises mingw): les initialiseurs désignés

Code:

struct s s1 = {.pf = f};

22/10/2008, 09h59
Médinoc

Est-on sûr que l'initialisation de la structure pthread_t est portable ?
N'a-t-on pas, normalement, à utiliser une fonction qui fait abstraction de cela ?
22/10/2008, 10h08
Emmanuel Delahaye
Citation:

Envoyé par nicolas.sitbon

Je conseille d'utiliser une des nouveautés du C99 (puisque tu utilises mingw): les initialiseurs désignés

Code:

struct s s1 = {pf = f};

Manque un . :

Code:

struct s s1 = {.pf = f};

Mais pour être portable, mieux vaut faire l'initialisation explicitement :
Code:

1 2 3 4 { struct s s1 = {0}; s1.pf = f;
22/10/2008, 10h11
nicolas.sitbon

Citation:

Envoyé par Médinoc

Est-on sûr que l'initialisation de la structure pthread_t est portable ?
N'a-t-on pas, normalement, à utiliser une fonction qui fait abstraction de cela ?

Effectivement, en théorie le type pthread_t doit être vu comme opaque et initialisé via pthread_create(). Tout autre utilisation n'est pas portable.
22/10/2008, 10h13
nicolas.sitbon
Citation:

Envoyé par Emmanuel Delahaye

Manque un . :

Code:

struct s s1 = {.pf = f};

corrigé.
Citation:
Envoyé par Emmanuel Delahaye

Mais pour être portable, mieux vaut faire l'initialisation explicitement :

Code:

1 2 3 struct s s1 = {0}; s1.pf = f;
les initialiseurs désignés sont tous ce qu'il y a de plus standard (C99) donc portable.
22/10/2008, 10h21
Emmanuel Delahaye

Citation:

Envoyé par nicolas.sitbon

les initialiseurs désignés sont tous ce qu'il y a de plus standard (C99) donc portable.

Bah pas sous Visual Studio...

standard != portable. Ce serait trop simple...
22/10/2008, 10h50
Médinoc

Et oui! L'équipe de Visual Studio n'a que faire de C99, même quand on leur met la tête dans les problèmes que ça cause.
22/10/2008, 10h55
nicolas.sitbon

Citation:

Envoyé par Emmanuel Delahaye

Bah pas sous Visual Studio...

standard != portable. Ce serait trop simple...

Citation:

Envoyé par Médinoc

Et oui! L'équipe de Visual Studio n'a que faire de C99, même quand on leur met la tête dans les problèmes que ça cause.

J'ai déjà dit ce que j'en pensais, il y a des alternatives plus "professionnelles" à visual Studio, conforme au C99. Il faut savoir choisir ses outils...
22/10/2008, 11h33
Emmanuel Delahaye

Citation:

Envoyé par nicolas.sitbon

J'ai déjà dit ce que j'en pensais, il y a des alternatives plus "professionnelles" à visual Studio, conforme au C99. Il faut savoir choisir ses outils...

Des exemples ?

Pour faire du développement sérieux sous Windows, je pense qu'il est difficile d'échapper au débugger de Microsoft (le seul à ma connaissance capable de suivre pas à pas le code, même quand il entre ou sort d'une DLL), ce qui impose l'usage de Visual Studio et donc d'abandonner C99.

Mais si une alternative aussi puissante existe, c'est OK.
22/10/2008, 11h36
nicolas.sitbon

Citation:

Envoyé par Emmanuel Delahaye

Des exemples ?

Pour faire du développement sérieux sous Windows, je pense qu'il est difficile d'échapper au débugger de Microsoft (le seul à ma connaissance capable de suivre pas à pas le code, même quand il entre ou sort d'une DLL), ce qui impose l'usage de Visual Studio et donc d'abandonner C99.

Mais si une alternative aussi puissante existe, c'est OK.

Comeau + dinkumware.
22/10/2008, 11h38
Médinoc

Comeau a fait un debugger ?
Ou bien parles-tu d'intégrer Comeau dans Visual ?
22/10/2008, 11h41
nicolas.sitbon

Citation:

Envoyé par Médinoc

Comeau a fait un debugger ?
Ou bien parles-tu d'intégrer Comeau dans Visual ?

Non mais il est compatible avec le debugger de Visual.
22/10/2008, 11h43
nicolas.sitbon

Citation:

Envoyé par Médinoc

Ou bien parles-tu d'intégrer Comeau dans Visual ?

Au moins pour debugger. Autrement Comeau dispose d'un front-end à son compilateur (que je n'ai pas testé pour le moment).

Bonsoir,

Citation:

Envoyé par Emmanuel Delahaye

Ceci fonctionne (en C, évidemment) :
[...]

J'ai essayé ça qui a l'air portable :

Code:

struct s s1 = {{0}, f};

Mais GCC se plaint si j'utilise -Wextra, il abuse non ?
Finalement je crois que je vais arrêter de toucher moi-même aux pthread_t, ce sera sûrement plus simple.
Citation:
Envoyé par nicolas.sitbon
Sous WIN32, pthread_t est défini ainsi :
Code:

1 2 3 4 5 6 7 typedef struct { void * p; /* Pointer to actual object */ unsigned int x; /* Extra information - reuse count etc */ } ptw32_handle_t; typedef ptw32_handle_t pthread_t;
Je conseille d'utiliser une des nouveautés du C99 (puisque tu utilises mingw): les initialiseurs désignés

Code:

struct s s1 = {.pf = f};
Je préfère utiliser C89 tant que c'est possible. Mais maintenant je sais au moins d'où vient cette syntaxe bizarre. :koi:

Citation:

Envoyé par Médinoc

Est-on sûr que l'initialisation de la structure pthread_t est portable ?
N'a-t-on pas, normalement, à utiliser une fonction qui fait abstraction de cela ?

À ma connaissance la norme n'impose rien pour le type qu'aliase pthread_t. Sous Linux c'est un entier, sous FreeBSD c'est un pointeur vers une structure.
La seule fonction que j'ai vue dans ce genre-là c'est pthread_equal().

22/10/2008, 20h07
nicolas.sitbon

Citation:

Envoyé par dapounet

Mais GCC se plaint si j'utilise -Wextra, il abuse non ?

Il abuse, certe.

Citation:

Envoyé par dapounet

Je préfère utiliser C89 tant que c'est possible. Mais maintenant je sais au moins d'où vient cette syntaxe bizarre. :koi:

Bizarre peut être, pratique, certainement.

Citation:

Envoyé par dapounet

À ma connaissance la norme n'impose rien pour le type qu'aliase pthread_t. Sous Linux c'est un entier, sous FreeBSD c'est un pointeur vers une structure.
La seule fonction que j'ai vue dans ce genre-là c'est pthread_equal().

Pour moi il n'y a aucune raison à aller trifouiller un type opaque. C'est le principe même de l'encapsulation.
22/10/2008, 21h53
dapounet

Citation:

Envoyé par nicolas.sitbon

Pour moi il n'y a aucune raison à aller trifouiller un type opaque. C'est le principe même de l'encapsulation.

Ce serait quand même plus simple si on pouvait être sûr que pthread_t est un pointeur (et ça ne limiterait pas les implémentations), si je n'avais pas compilé mon code sous Windows je ne me serais sûrement jamais rendu compte de ce problème de portabilité.
22/10/2008, 22h01
nicolas.sitbon

Citation:

IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, adding pthread_t to the list of types that are not required to be arithmetic types, thus allowing pthread_t to be defined as a structure.