🚀 go-pugleaf

"James Kanze" <kanze@gabi-soft.de> a �crit dans le message news:
d6651fb6.0109260316.26ca0440@posting.google.com...
> "Thierry Noc" <svill@free.fr> wrote in message
> news:<c50ro9.ek.ln@musashi.ps>...
>
> > d6651fb6.0109250117.27f6c56a@posting.google.com...
>
> > > > 2) sa puret� dans la gestion des theads. (mutex, synchro, rt..) par
> > > > rapport � un un sun2.6 sur un ultra-sparc4. (les 2 vont bien
> > > > ensemble car du m�me constructeur :o)
>
> > > Tu peux oublier les threads avec g++. La biblioth�que n'est pas
> > > thread-safe. Et au moins sous Solaris, m�me sans utiliser la
> > > biblioth�que standard, il faut de la gymnasitique pour que les
> > > appels syst�mes soit thread safe.
>
> > Aucune libc++ n'est a ma connaissance thread safe.
>
> Le premier probl�me avec g++, c'�tait std::string. Et sans pouvoir
> utiliser std::string, o� est l'inter�t du C++ sur C ?
>
> > En revanche les appels syst�mes le sont, si c'est pas le cas sous
> > Solaris, poubelle.
>
> > > > votre exp�rience m'int�resse :o)
>
> > > Mon exp�rience, c'est que g++ et multi-threading ne vont pas
> > > ensemble. Et crois moi, on a essay�.
>
> > La mienne est positive. J'ai globalement expliqu� il y a quelque
> > temps dans ce forum (fclc++) les techniques que j'utilise pour
> > rendre la libc++ thread safe. (rien de sorcier mais HS en fait ).
>
> Je ne sais pas d'o� exactement vient le probl�me. Je sais que g++ en
> fait ne conna�t pas des threads. Ce qui veut pas dire qu'on ne peut
> pas le � tricher � pour que les threads marchent ; c'est m�me possible
> que sur certains syst�mes (mais non Solaris) ils marchent par d�faut.
> Mais c'est un accident quand ils marchent ; un al�a de la fa�on que
> g++ g�n�re son code, ses appels de l'�diteur de liens, etc., et non le
> r�sultat d'une action concr�te de la part des auteurs de g++.
>
> Je crois savoir comment faire que le compilateur soit thread-safe sous
> Solaris, mais il reste le probl�me des biblioth�ques. � quoi bon un
> compilateur C++ sans biblioth�que standard ?
>
> (Je dois ajouter que mes essais �taient avec 2.95.2. Il y a eu des
> efforts sur les threads dans la biblioth�que 3.0.x ; je ferais des
> essais d�s que je trouve le temps, mais ayant jet� un coup d'oeil sur
> les sources, je ne suis pas optimiste.)

C'est pas une question de compilateur ni de lib.
J'ai une appli thread�e en gcc 2.7.x qui utilise a fond std:: et qui tourne
encore. Et ca tabasse dur.