[Squeak-fr] Re: Re: Squeak est multithreadé

[alr]

Effectivement ca n'est pas supporté aujourd'hui dans la VM.
Un  Process squeak n'est pas un thread OS  !!!
Un Process squeak ne créee pas de threads OS. Il y a quelques threads spécifiques pour les async IO (sockets, son etc) , sinon tous les process s'éxécutent ds le même thread OS qui est celui de la VM squeak et c'est la VM qui gère le changement de context des process, pas le système.
(pour le vérifier sous windows par exemple, ajouter une colonne nbre de threads ds le gestionnaire de taches et executer le code suivant:
[  Transcript show: 'aaa'. 
 (Delay forSeconds: 10 ) wait. 
 Transcript show: 'ok'. 
 ] fork
on voit qu'il n'y a pas de threads windows)

Dans ce sens, squeak n'est pas multithread natif et un appel FFI (cas de l'exemple ODBC) bloque effectivement la VM, avec ou sans Process squeak et semaphore ( il ne s'agit pas non plus des call-backs qui ne résolvent pas non plus ce pbm).
La solution est celle qui est implémentée ds la VM aujourd'hui pour les asyncio, cad créer un thread windows, faire un waitforsingle object etc...
cad gérer soit même un nouveau thread ds la dll, ce qui permet de rendre la main au thread de la VM et de ne pas bloquer le système.
Et effectivement le problème du multiprocesseur est très certainement beaucoup plus pointu (quoique déjà un garbage collector multithread implique pas mal de chose dans la VM, ou même simplement un accès d'une méthode sur un objet qui doit gérer un lock potentiel sur chaque objet) .

De toutes facons, et c'est aussi ce qui ressort de posts sur le sujet, pour faire du multiprocesseur il faudra passer par du vrai multi-threads...
  "Bernard Pottier" <pottier at univ-brest.fr> a écrit dans le message de news: 43724348.9000200 at univ-brest.fr...
  Samuel Tardieu wrote: 
"Noury" == Noury Bouraqadi <bouraqadi at ensm-douai.fr> writes:
             le seul inconvénient que g rencontré c le fait que squeak ne soit
pas multithread donc tu la fait ds le thread de squeak et
l'affichage se fige si ta requete est longue, mais beaucoup d
elogiciels commerciaux sont ds ce cas - même le requêteur TOAD pour
ORACLE!!!- , c pas bloquant.
      
Noury> Non ! Squeak (Smalltalk) est bel et bien multi-threadé !  Il y
Noury> a d'ailleurs en permanence une dizaine de threads qui tournent
Noury> (cf. ProcessBrowser dans le flap Tools).

Tu parles de threads utilisateur, le posteur original de threads
systeme. Si, par exemple par le biais d'un appel FFI, tu fais un appel
bloquant a un driver par exemple, Squeak en entier sera bloque.
  Oui si c'est mal programmé et pas supporté dans la MV.

  Normalement celle-ci doit prévoir un sémaphore pour synchroniser
  une primitive avec avec le processus de haut niveau (que l'on doit écrire),
  et là pas de bloquage de squeak.

  Le vrai probleme est le multiprocessing, c'est à dire la capacité
  de la MV à allouer des processeurs sur les machines paralleles
  ou les multicore que l'on a actuellement. Dans ce sens, squeak,
  et à ma connaissance VW, ne supportent pas le multiprocessing:
  la MV devra etre revue avec des questions très intéressantes
  à traiter.

  Cordialement
  Bernard Pottier


  Sam
  



------------------------------------------------------------------------------


  _______________________________________________
  Squeak-fr mailing list
  Squeak-fr at lists.squeakfoundation.org
  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
-------------- section suivante --------------
Une pièce jointe HTML a été enlevée...
URL: http://liststest.squeakfoundation.org/pipermail/squeak-fr/attachments/20051109/e57bc59a/attachment.html