Je suis en train de développer une application C++ avec Borland C++ 5.0. Une
de ses fonctions lance un thread assez consommateur mais qui effectue
correctement son travail. Systématiquement lorsque je quitte mon appli alors
que ce thread a été lancé (et à priori terminé), mon PC se gèle totalement
(sauf la souris) pendant plusieurs secondes.
Si par contre le thread n'est pas lancé, tout se passe bien.
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
Patrick D.
On Tue, 30 Dec 2003 17:31:08 +0100, Seb wrote:
Bonjour,
Je suis en train de développer une application C++ avec Borland C++ 5.0. Une de ses fonctions lance un thread assez consommateur mais qui effectue correctement son travail. Systématiquement lorsque je quitte mon appli alors que ce thread a été lancé (et à priori terminé), mon PC se gèle totalement (sauf la souris) pendant plusieurs secondes.
Si par contre le thread n'est pas lancé, tout se passe bien.
Avez-vous déjà rencontré ce problème ?
Sébastien
j'aime beaucoup le 'à priori terminé' faudrait peut-être mieux s'assurer qu'il l'est ....
-- * enlevez '.don't.spam' et '.invalid' de mon adresse eMail si vous voulez m'écrire * * Donne un poisson à un homme, il aura à manger pour un jour * Apprends-lui à pêcher, il aura à manger pour tous les jours de sa vie *
On Tue, 30 Dec 2003 17:31:08 +0100, Seb <nospam@yahoo.net> wrote:
Bonjour,
Je suis en train de développer une application C++ avec Borland C++ 5.0.
Une
de ses fonctions lance un thread assez consommateur mais qui effectue
correctement son travail. Systématiquement lorsque je quitte mon appli
alors
que ce thread a été lancé (et à priori terminé), mon PC se gèle
totalement
(sauf la souris) pendant plusieurs secondes.
Si par contre le thread n'est pas lancé, tout se passe bien.
Avez-vous déjà rencontré ce problème ?
Sébastien
j'aime beaucoup le 'à priori terminé'
faudrait peut-être mieux s'assurer qu'il l'est ....
--
* enlevez '.don't.spam' et '.invalid' de mon adresse eMail si vous voulez
m'écrire *
* Donne un poisson à un homme, il aura à manger pour un jour
* Apprends-lui à pêcher, il aura à manger pour tous les jours de sa vie *
Je suis en train de développer une application C++ avec Borland C++ 5.0. Une de ses fonctions lance un thread assez consommateur mais qui effectue correctement son travail. Systématiquement lorsque je quitte mon appli alors que ce thread a été lancé (et à priori terminé), mon PC se gèle totalement (sauf la souris) pendant plusieurs secondes.
Si par contre le thread n'est pas lancé, tout se passe bien.
Avez-vous déjà rencontré ce problème ?
Sébastien
j'aime beaucoup le 'à priori terminé' faudrait peut-être mieux s'assurer qu'il l'est ....
-- * enlevez '.don't.spam' et '.invalid' de mon adresse eMail si vous voulez m'écrire * * Donne un poisson à un homme, il aura à manger pour un jour * Apprends-lui à pêcher, il aura à manger pour tous les jours de sa vie *
Seb
"Patrick D." <patrickr.dubois.don' a écrit dans le message news:
On Tue, 30 Dec 2003 17:31:08 +0100, Seb wrote:
> Bonjour, > > Je suis en train de développer une application C++ avec Borland C++ 5.0. > Une > de ses fonctions lance un thread assez consommateur mais qui effectue > correctement son travail. Systématiquement lorsque je quitte mon appli > alors > que ce thread a été lancé (et à priori terminé), mon PC se gèle > totalement > (sauf la souris) pendant plusieurs secondes. > > Si par contre le thread n'est pas lancé, tout se passe bien. > > Avez-vous déjà rencontré ce problème ? > > Sébastien > >
j'aime beaucoup le 'à priori terminé' faudrait peut-être mieux s'assurer qu'il l'est ....
En fait, la documentation spécifie que le thread se termine une fois qu'il a atteind la fin de sa fonction Run(). C'est effectivement mon cas. D'autre part, utilisant un pointeur sur un objet dérivé de TThread, un delete est effectué et il ne retourne pas d'erreur. Je dis à priori parce que techniquement, tout porte à croire que le thread est terminé, mais j'ai le sentiment que mon erreur viens de là.
Si vous avez une idée pour qu'au moment ou mon application je puisse présenter (sous forme de trace par exemple) la liste des threads actifs avec Borland C++ 5 je suis preneur.
Sébastien
"Patrick D." <patrickr.dubois.don't.spam@free.fr> a écrit dans le message
news: opr0z6wilqul3rue@news.free.fr...
On Tue, 30 Dec 2003 17:31:08 +0100, Seb <nospam@yahoo.net> wrote:
> Bonjour,
>
> Je suis en train de développer une application C++ avec Borland C++ 5.0.
> Une
> de ses fonctions lance un thread assez consommateur mais qui effectue
> correctement son travail. Systématiquement lorsque je quitte mon appli
> alors
> que ce thread a été lancé (et à priori terminé), mon PC se gèle
> totalement
> (sauf la souris) pendant plusieurs secondes.
>
> Si par contre le thread n'est pas lancé, tout se passe bien.
>
> Avez-vous déjà rencontré ce problème ?
>
> Sébastien
>
>
j'aime beaucoup le 'à priori terminé'
faudrait peut-être mieux s'assurer qu'il l'est ....
En fait, la documentation spécifie que le thread se termine une fois qu'il a
atteind la fin de sa fonction Run(). C'est effectivement mon cas. D'autre
part, utilisant un pointeur sur un objet dérivé de TThread, un delete est
effectué et il ne retourne pas d'erreur. Je dis à priori parce que
techniquement, tout porte à croire que le thread est terminé, mais j'ai le
sentiment que mon erreur viens de là.
Si vous avez une idée pour qu'au moment ou mon application je puisse
présenter (sous forme de trace par exemple) la liste des threads actifs avec
Borland C++ 5 je suis preneur.
"Patrick D." <patrickr.dubois.don' a écrit dans le message news:
On Tue, 30 Dec 2003 17:31:08 +0100, Seb wrote:
> Bonjour, > > Je suis en train de développer une application C++ avec Borland C++ 5.0. > Une > de ses fonctions lance un thread assez consommateur mais qui effectue > correctement son travail. Systématiquement lorsque je quitte mon appli > alors > que ce thread a été lancé (et à priori terminé), mon PC se gèle > totalement > (sauf la souris) pendant plusieurs secondes. > > Si par contre le thread n'est pas lancé, tout se passe bien. > > Avez-vous déjà rencontré ce problème ? > > Sébastien > >
j'aime beaucoup le 'à priori terminé' faudrait peut-être mieux s'assurer qu'il l'est ....
En fait, la documentation spécifie que le thread se termine une fois qu'il a atteind la fin de sa fonction Run(). C'est effectivement mon cas. D'autre part, utilisant un pointeur sur un objet dérivé de TThread, un delete est effectué et il ne retourne pas d'erreur. Je dis à priori parce que techniquement, tout porte à croire que le thread est terminé, mais j'ai le sentiment que mon erreur viens de là.
Si vous avez une idée pour qu'au moment ou mon application je puisse présenter (sous forme de trace par exemple) la liste des threads actifs avec Borland C++ 5 je suis preneur.
Sébastien
Kaos Voyager
www.sysinternals.com
--> Process Viewer v8.10
"Seb" a écrit dans le message de news:bsuf80$n1b$
"Patrick D." <patrickr.dubois.don' a écrit dans le message news: > On Tue, 30 Dec 2003 17:31:08 +0100, Seb wrote: > > > Bonjour, > > > > Je suis en train de développer une application C++ avec Borland C++
5.0.
> > Une > > de ses fonctions lance un thread assez consommateur mais qui effectue > > correctement son travail. Systématiquement lorsque je quitte mon appli > > alors > > que ce thread a été lancé (et à priori terminé), mon PC se gèle > > totalement > > (sauf la souris) pendant plusieurs secondes. > > > > Si par contre le thread n'est pas lancé, tout se passe bien. > > > > Avez-vous déjà rencontré ce problème ? > > > > Sébastien > > > > > > j'aime beaucoup le 'à priori terminé' > faudrait peut-être mieux s'assurer qu'il l'est .... >
En fait, la documentation spécifie que le thread se termine une fois qu'il
a
atteind la fin de sa fonction Run(). C'est effectivement mon cas. D'autre part, utilisant un pointeur sur un objet dérivé de TThread, un delete est effectué et il ne retourne pas d'erreur. Je dis à priori parce que techniquement, tout porte à croire que le thread est terminé, mais j'ai le sentiment que mon erreur viens de là.
Si vous avez une idée pour qu'au moment ou mon application je puisse présenter (sous forme de trace par exemple) la liste des threads actifs
avec
Borland C++ 5 je suis preneur.
Sébastien
www.sysinternals.com
--> Process Viewer v8.10
"Seb" <nospam@yahoo.net> a écrit dans le message de
news:bsuf80$n1b$1@s1.read.news.oleane.net...
"Patrick D." <patrickr.dubois.don't.spam@free.fr> a écrit dans le message
news: opr0z6wilqul3rue@news.free.fr...
> On Tue, 30 Dec 2003 17:31:08 +0100, Seb <nospam@yahoo.net> wrote:
>
> > Bonjour,
> >
> > Je suis en train de développer une application C++ avec Borland C++
5.0.
> > Une
> > de ses fonctions lance un thread assez consommateur mais qui effectue
> > correctement son travail. Systématiquement lorsque je quitte mon appli
> > alors
> > que ce thread a été lancé (et à priori terminé), mon PC se gèle
> > totalement
> > (sauf la souris) pendant plusieurs secondes.
> >
> > Si par contre le thread n'est pas lancé, tout se passe bien.
> >
> > Avez-vous déjà rencontré ce problème ?
> >
> > Sébastien
> >
> >
>
> j'aime beaucoup le 'à priori terminé'
> faudrait peut-être mieux s'assurer qu'il l'est ....
>
En fait, la documentation spécifie que le thread se termine une fois qu'il
a
atteind la fin de sa fonction Run(). C'est effectivement mon cas. D'autre
part, utilisant un pointeur sur un objet dérivé de TThread, un delete est
effectué et il ne retourne pas d'erreur. Je dis à priori parce que
techniquement, tout porte à croire que le thread est terminé, mais j'ai le
sentiment que mon erreur viens de là.
Si vous avez une idée pour qu'au moment ou mon application je puisse
présenter (sous forme de trace par exemple) la liste des threads actifs
"Patrick D." <patrickr.dubois.don' a écrit dans le message news: > On Tue, 30 Dec 2003 17:31:08 +0100, Seb wrote: > > > Bonjour, > > > > Je suis en train de développer une application C++ avec Borland C++
5.0.
> > Une > > de ses fonctions lance un thread assez consommateur mais qui effectue > > correctement son travail. Systématiquement lorsque je quitte mon appli > > alors > > que ce thread a été lancé (et à priori terminé), mon PC se gèle > > totalement > > (sauf la souris) pendant plusieurs secondes. > > > > Si par contre le thread n'est pas lancé, tout se passe bien. > > > > Avez-vous déjà rencontré ce problème ? > > > > Sébastien > > > > > > j'aime beaucoup le 'à priori terminé' > faudrait peut-être mieux s'assurer qu'il l'est .... >
En fait, la documentation spécifie que le thread se termine une fois qu'il
a
atteind la fin de sa fonction Run(). C'est effectivement mon cas. D'autre part, utilisant un pointeur sur un objet dérivé de TThread, un delete est effectué et il ne retourne pas d'erreur. Je dis à priori parce que techniquement, tout porte à croire que le thread est terminé, mais j'ai le sentiment que mon erreur viens de là.
Si vous avez une idée pour qu'au moment ou mon application je puisse présenter (sous forme de trace par exemple) la liste des threads actifs
avec
Borland C++ 5 je suis preneur.
Sébastien
Seb
"Kaos Voyager" a écrit dans le message news: 3ff41238$0$19296$
www.sysinternals.com
--> Process Viewer v8.10
Merci, j'ai pu identifier que mon thread s'arrête. En fait mon souci semble venir du fait que j'utilise le BDE avec plusieurs thread. Quelqu'un a-t-il déjà eu des problèmes avec une telle architecture ?
Sébastien
"Kaos Voyager" <_@_> a écrit dans le message news:
3ff41238$0$19296$626a54ce@news.free.fr...
www.sysinternals.com
--> Process Viewer v8.10
Merci, j'ai pu identifier que mon thread s'arrête. En fait mon souci semble
venir du fait que j'utilise le BDE avec plusieurs thread. Quelqu'un a-t-il
déjà eu des problèmes avec une telle architecture ?
"Kaos Voyager" a écrit dans le message news: 3ff41238$0$19296$
www.sysinternals.com
--> Process Viewer v8.10
Merci, j'ai pu identifier que mon thread s'arrête. En fait mon souci semble venir du fait que j'utilise le BDE avec plusieurs thread. Quelqu'un a-t-il déjà eu des problèmes avec une telle architecture ?
Sébastien
Manuel Leclerc
Seb a écrit :
Merci, j'ai pu identifier que mon thread s'arrête. En fait mon souci semble venir du fait que j'utilise le BDE avec plusieurs thread. Quelqu'un a-t-il déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en Multi-Thread sur une machine multi-processeurs. Mais c'était du Delphi3 :-) J'ose espérer que ça va mieux avec les versions récentes.
Je ne peux que te conseiller de changer de newsgroup et d'aller en particulier sous la hierarchie borland.public.* mais pas sans avoir bien fait chauffer Google avant.
Seb a écrit :
Merci, j'ai pu identifier que mon thread s'arrête.
En fait mon souci semble venir du fait que j'utilise
le BDE avec plusieurs thread. Quelqu'un a-t-il
déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en
Multi-Thread sur une machine multi-processeurs.
Mais c'était du Delphi3 :-)
J'ose espérer que ça va mieux avec les versions
récentes.
Je ne peux que te conseiller de changer de newsgroup
et d'aller en particulier sous la hierarchie borland.public.*
mais pas sans avoir bien fait chauffer Google avant.
Merci, j'ai pu identifier que mon thread s'arrête. En fait mon souci semble venir du fait que j'utilise le BDE avec plusieurs thread. Quelqu'un a-t-il déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en Multi-Thread sur une machine multi-processeurs. Mais c'était du Delphi3 :-) J'ose espérer que ça va mieux avec les versions récentes.
Je ne peux que te conseiller de changer de newsgroup et d'aller en particulier sous la hierarchie borland.public.* mais pas sans avoir bien fait chauffer Google avant.
Seb
"Manuel Leclerc" a écrit dans le message news:
Seb a écrit :
> Merci, j'ai pu identifier que mon thread s'arrête. > En fait mon souci semble venir du fait que j'utilise > le BDE avec plusieurs thread. Quelqu'un a-t-il > déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en Multi-Thread sur une machine multi-processeurs. Mais c'était du Delphi3 :-) J'ose espérer que ça va mieux avec les versions récentes.
Je ne peux que te conseiller de changer de newsgroup et d'aller en particulier sous la hierarchie borland.public.* mais pas sans avoir bien fait chauffer Google avant.
Mon cas est en C++.
Merci du conseil mais "borland.public.bde" fait la sourde oreille depuis 2 jours. QUant à google j'y travaille.
Sébastien
"Manuel Leclerc" <manuel.leclerc@alussinan.org> a écrit dans le message
news: 3ffbe170@neottia.net...
Seb a écrit :
> Merci, j'ai pu identifier que mon thread s'arrête.
> En fait mon souci semble venir du fait que j'utilise
> le BDE avec plusieurs thread. Quelqu'un a-t-il
> déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en
Multi-Thread sur une machine multi-processeurs.
Mais c'était du Delphi3 :-)
J'ose espérer que ça va mieux avec les versions
récentes.
Je ne peux que te conseiller de changer de newsgroup
et d'aller en particulier sous la hierarchie borland.public.*
mais pas sans avoir bien fait chauffer Google avant.
Mon cas est en C++.
Merci du conseil mais "borland.public.bde" fait la sourde oreille depuis 2
jours. QUant à google j'y travaille.
> Merci, j'ai pu identifier que mon thread s'arrête. > En fait mon souci semble venir du fait que j'utilise > le BDE avec plusieurs thread. Quelqu'un a-t-il > déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en Multi-Thread sur une machine multi-processeurs. Mais c'était du Delphi3 :-) J'ose espérer que ça va mieux avec les versions récentes.
Je ne peux que te conseiller de changer de newsgroup et d'aller en particulier sous la hierarchie borland.public.* mais pas sans avoir bien fait chauffer Google avant.
Mon cas est en C++.
Merci du conseil mais "borland.public.bde" fait la sourde oreille depuis 2 jours. QUant à google j'y travaille.
Sébastien
Johann Dantant
"Manuel Leclerc" a écrit dans le message de news:
Seb a écrit :
> Merci, j'ai pu identifier que mon thread s'arrête. > En fait mon souci semble venir du fait que j'utilise > le BDE avec plusieurs thread. Quelqu'un a-t-il > déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en Multi-Thread sur une machine multi-processeurs. Mais c'était du Delphi3 :-) J'ose espérer que ça va mieux avec les versions récentes.
C'est pareil avec Delphi6 et une version décemment récente de C++Builder. Ca n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit laisser tomber le BDE et utiliser un autres moyen d'accès aux données (pertinent mais fastidieux...), soit laisser tous les traitements BDE dans le thread principal de l'application (déprimant mais plus rapide ???...)...
"Manuel Leclerc" <manuel.leclerc@alussinan.org> a écrit dans le message de
news:3ffbe170@neottia.net...
Seb a écrit :
> Merci, j'ai pu identifier que mon thread s'arrête.
> En fait mon souci semble venir du fait que j'utilise
> le BDE avec plusieurs thread. Quelqu'un a-t-il
> déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en
Multi-Thread sur une machine multi-processeurs.
Mais c'était du Delphi3 :-)
J'ose espérer que ça va mieux avec les versions
récentes.
C'est pareil avec Delphi6 et une version décemment récente de C++Builder. Ca
n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins
jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande
même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit
laisser tomber le BDE et utiliser un autres moyen d'accès aux données
(pertinent mais fastidieux...), soit laisser tous les traitements BDE dans
le thread principal de l'application (déprimant mais plus rapide ???...)...
> Merci, j'ai pu identifier que mon thread s'arrête. > En fait mon souci semble venir du fait que j'utilise > le BDE avec plusieurs thread. Quelqu'un a-t-il > déjà eu des problèmes avec une telle architecture ?
Moi, j'ai eu des problèmes avec Delphi en Multi-Thread sur une machine multi-processeurs. Mais c'était du Delphi3 :-) J'ose espérer que ça va mieux avec les versions récentes.
C'est pareil avec Delphi6 et une version décemment récente de C++Builder. Ca n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit laisser tomber le BDE et utiliser un autres moyen d'accès aux données (pertinent mais fastidieux...), soit laisser tous les traitements BDE dans le thread principal de l'application (déprimant mais plus rapide ???...)...
Seb
"Johann Dantant" a écrit dans le message news: bth1sc$au3$
"Manuel Leclerc" a écrit dans le message de news: > Seb a écrit : > > > Merci, j'ai pu identifier que mon thread s'arrête. > > En fait mon souci semble venir du fait que j'utilise > > le BDE avec plusieurs thread. Quelqu'un a-t-il > > déjà eu des problèmes avec une telle architecture ? > > Moi, j'ai eu des problèmes avec Delphi en > Multi-Thread sur une machine multi-processeurs. > Mais c'était du Delphi3 :-) > J'ose espérer que ça va mieux avec les versions > récentes. >
C'est pareil avec Delphi6 et une version décemment récente de C++Builder.
Ca
n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit laisser tomber le BDE et utiliser un autres moyen d'accès aux données (pertinent mais fastidieux...), soit laisser tous les traitements BDE dans le thread principal de l'application (déprimant mais plus rapide
???...)...
Merci beaucoup pour cette remarque déprimante en effet mais précise.
Si vous aviez une appli à faire migrer de BDE vers .... Que choisiriez-vous ?
Sebastien
"Johann Dantant" <johann.d@pro-active.frog.INVALID> a écrit dans le message
news: bth1sc$au3$1@news-reader2.wanadoo.fr...
"Manuel Leclerc" <manuel.leclerc@alussinan.org> a écrit dans le message de
news:3ffbe170@neottia.net...
> Seb a écrit :
>
> > Merci, j'ai pu identifier que mon thread s'arrête.
> > En fait mon souci semble venir du fait que j'utilise
> > le BDE avec plusieurs thread. Quelqu'un a-t-il
> > déjà eu des problèmes avec une telle architecture ?
>
> Moi, j'ai eu des problèmes avec Delphi en
> Multi-Thread sur une machine multi-processeurs.
> Mais c'était du Delphi3 :-)
> J'ose espérer que ça va mieux avec les versions
> récentes.
>
C'est pareil avec Delphi6 et une version décemment récente de C++Builder.
Ca
n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins
jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande
même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit
laisser tomber le BDE et utiliser un autres moyen d'accès aux données
(pertinent mais fastidieux...), soit laisser tous les traitements BDE dans
le thread principal de l'application (déprimant mais plus rapide
???...)...
Merci beaucoup pour cette remarque déprimante en effet mais précise.
Si vous aviez une appli à faire migrer de BDE vers .... Que choisiriez-vous
?
"Johann Dantant" a écrit dans le message news: bth1sc$au3$
"Manuel Leclerc" a écrit dans le message de news: > Seb a écrit : > > > Merci, j'ai pu identifier que mon thread s'arrête. > > En fait mon souci semble venir du fait que j'utilise > > le BDE avec plusieurs thread. Quelqu'un a-t-il > > déjà eu des problèmes avec une telle architecture ? > > Moi, j'ai eu des problèmes avec Delphi en > Multi-Thread sur une machine multi-processeurs. > Mais c'était du Delphi3 :-) > J'ose espérer que ça va mieux avec les versions > récentes. >
C'est pareil avec Delphi6 et une version décemment récente de C++Builder.
Ca
n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit laisser tomber le BDE et utiliser un autres moyen d'accès aux données (pertinent mais fastidieux...), soit laisser tous les traitements BDE dans le thread principal de l'application (déprimant mais plus rapide
???...)...
Merci beaucoup pour cette remarque déprimante en effet mais précise.
Si vous aviez une appli à faire migrer de BDE vers .... Que choisiriez-vous ?
Sebastien
Manuel Leclerc
Johann Dantant a écrit :
Manuel Leclerc a écrit :
> Moi, j'ai eu des problèmes avec Delphi en > Multi-Thread sur une machine multi-processeurs. > Mais c'était du Delphi3 :-) > J'ose espérer que ça va mieux avec les versions > récentes.
C'est pareil avec Delphi6 et une version décemment récente de C++Builder. Ca n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit laisser tomber le BDE et utiliser un autres moyen d'accès aux données (pertinent mais fastidieux...), soit laisser tous les traitements BDE dans le thread principal de l'application (déprimant mais plus rapide ???...)...
Pour ce qui est d'un vieux BDE et le multi-thread, je m'en étais sorti à l'époque en conservant les threads mais en sérialisant les accés SQL, car mes traitements ce n'étaient pas que du SQL. Je te trouve quand même bien sévère à propos du BDE. Il y a des bugs, surtout dans les vieilles versions, mais il y a aussi beaucoup de truc qui marche très bien :-) surtout si on passe _beaucoup_ de temps à lire la doc et les exemples qui traînent un peu partout :-(
Mais le truc que j'avais trouvé vraiment pénible, c'était des corruptions dans les "strings" pascal sur une machine multi-processeurs (avec D3). Et ça c'était bel et bien lié à la plateforme, il y a des programmes multi-thread qui "marchent" sur un seul processeur et qui se vautrent lamentablement sur plusieurs :-)
Le BDE de toute façon, ça a été remplacée par dbExpress, il me semble.
Johann Dantant a écrit :
Manuel Leclerc a écrit :
> Moi, j'ai eu des problèmes avec Delphi en
> Multi-Thread sur une machine multi-processeurs.
> Mais c'était du Delphi3 :-)
> J'ose espérer que ça va mieux avec les versions
> récentes.
C'est pareil avec Delphi6 et une version décemment récente
de C++Builder. Ca n'a d'ailleurs rien à voir avec
l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?)
lui-même qui n'est pas multi-thread safe (on se demande
même s'il est usage safe, mais bon)... En gros tu as 2
possibilités : soit laisser tomber le BDE et utiliser un
autres moyen d'accès aux données (pertinent mais fastidieux...),
soit laisser tous les traitements BDE dans le thread principal
de l'application (déprimant mais plus rapide ???...)...
Pour ce qui est d'un vieux BDE et le multi-thread, je m'en étais
sorti à l'époque en conservant les threads mais en sérialisant
les accés SQL, car mes traitements ce n'étaient pas que du SQL.
Je te trouve quand même bien sévère à propos du BDE. Il y a des
bugs, surtout dans les vieilles versions, mais il y a aussi
beaucoup de truc qui marche très bien :-) surtout si on passe
_beaucoup_ de temps à lire la doc et les exemples qui traînent
un peu partout :-(
Mais le truc que j'avais trouvé vraiment pénible, c'était
des corruptions dans les "strings" pascal sur une machine
multi-processeurs (avec D3). Et ça c'était bel et bien lié
à la plateforme, il y a des programmes multi-thread qui
"marchent" sur un seul processeur et qui se vautrent
lamentablement sur plusieurs :-)
Le BDE de toute façon, ça a été remplacée par dbExpress, il
me semble.
> Moi, j'ai eu des problèmes avec Delphi en > Multi-Thread sur une machine multi-processeurs. > Mais c'était du Delphi3 :-) > J'ose espérer que ça va mieux avec les versions > récentes.
C'est pareil avec Delphi6 et une version décemment récente de C++Builder. Ca n'a d'ailleurs rien à voir avec l'environnement, c'est le BDE (au moins jusqu'au 5.xx ?) lui-même qui n'est pas multi-thread safe (on se demande même s'il est usage safe, mais bon)... En gros tu as 2 possibilités : soit laisser tomber le BDE et utiliser un autres moyen d'accès aux données (pertinent mais fastidieux...), soit laisser tous les traitements BDE dans le thread principal de l'application (déprimant mais plus rapide ???...)...
Pour ce qui est d'un vieux BDE et le multi-thread, je m'en étais sorti à l'époque en conservant les threads mais en sérialisant les accés SQL, car mes traitements ce n'étaient pas que du SQL. Je te trouve quand même bien sévère à propos du BDE. Il y a des bugs, surtout dans les vieilles versions, mais il y a aussi beaucoup de truc qui marche très bien :-) surtout si on passe _beaucoup_ de temps à lire la doc et les exemples qui traînent un peu partout :-(
Mais le truc que j'avais trouvé vraiment pénible, c'était des corruptions dans les "strings" pascal sur une machine multi-processeurs (avec D3). Et ça c'était bel et bien lié à la plateforme, il y a des programmes multi-thread qui "marchent" sur un seul processeur et qui se vautrent lamentablement sur plusieurs :-)
Le BDE de toute façon, ça a été remplacée par dbExpress, il me semble.
