Est-il possible d’avoir plusieurs objects ORB dans le même processus?

J’utilise ORBacus . J’ai une application multithreading et je veux avoir plusieurs objects ORB dans le même processus . L’idée est la suivante: chaque thread doit avoir son propre ORB et être connecté à un serveur différent .

Est-ce seulement possible? Si c’est le cas, comment?


Qu’as-tu essayé? “: J’ai

CORBA::ORB_var m_varOrb; 

dans chaque fil. Chaque fil appelle. Chaque thread a la méthode Reconnect , qui exécute:

 // ... m_varOrb = CORBA::ORB_init( argc, argv ); 

Les problèmes, j’ai:

  • lorsque plusieurs threads tentent de se reconnecter en même temps, l’application se bloque dans m_varOrb->destroy(); ou dans CORBA::ORB_init .

  • J’ai essayé de synchroniser les threads, de sorte que tous les threads essaient de se reconnecter au serveur configuré un à un (à l’aide d’un static mutex ) – toujours inefficace – lorsqu’un thread tente de détruire “son” object ORB – assert échoue, car le nombre de références est> 1; il ressemble à un pointeur de comptage de références sur l’object ORB réel.

  • J’ai ajouté une attente conditionnelle , donc les threads ne commencent à appeler ORB_init que lorsque tous les threads ont été exécutés. a créé une classe d’emballage singleton autour de l’ORB, synchronisé les threads pour se connecter les uns après les autres et que tout a commencé à fonctionner parfaitement. MAIS cela signifie – un seul ORB, donc un seul serveur. Mal.

Donc, toutes ces choses m’ont rendu sortingste, de ne pouvoir avoir qu’un seul object ORB par processus . Est-ce que je manque quelque chose?

    Par défaut, les ORB CORBA doivent se comporter comme des singletons si vous transmettez le même paramètre “ORB id” lors de leur ORB_init() avec ORB_init() . Cependant, vous passez probablement le même paramètre à chaque fois, ce qui signifie que l’ORB suppose que vous voulez que tous ces threads partagent la même instance ORB sous-jacente.

    La première chose à faire est donc de trouver dans la documentation d’ORBacus comment passer des ID ORB uniques dans chaque thread. Peut-être utiliser l’identifiant de fil comme discriminant.

    Cela dit, votre approche pourrait être améliorée. Créer un ORB dans chaque thread est une opération très coûteuse. Au lieu de cela, créez un ORB partagé au démarrage de l’application, puis autorisez chaque thread à y accéder. Il devrait déjà être protégé par ORBacus contre les access simultanés. Assurez-vous que vous ne faites que fermer / détruire ORB dans la ligne principale, pas dans les threads.