Dear all, I continue working in some task synchronization I referred to in a previous mail and I need some clarification to go on because I'm getting either dead-locks or crashes when trying to map a distributed object. The point is the following, I have a distributed object to help in the creation of application wide objects that I need to coordinate asynchronous tasks. That manager is created during config initialization and is registered and mapped similarly to the InitData from eqPly, with the difference that I don't unmap the object until nodeExit. The manager registers several commands which are used by the application node to signal client nodes to map/unmap additional objects. Then, I can register new objects in the application thread and afterwards tell the ID to the other nodes to map the object. The problem I have is when mapping the remote objects. If I register the manager's command to the receiver thread within the local node (passing 0 as the queue to registerCommand) the call to session->mapObject inside the command callback from the client blocks in the sync part. I guess this makes sense since the receiver thread probably needs to handle some packets to finalize the mapping and this code leads to a trivial dead-lock. But, if I register the command to the command thread as (in Barrier::attachToSession) the assert in Session::mapObjectNB line 341: EQASSERT( !_localNode->inCommandThread( )); fails. Obviously the assert is right but from what I've seen in the barrier code, the command callback Window::_cmdBarrier ends up calling mapObject to map the barrier object in slave nodes and I guess that works fine. It's also true that the window commands are dispatched by the pipe thread. So I guess that I'll have to create my own dispatcher thread to handle these commands. What I'd like to know is whether my deduction is right and if there is any other alternative to having to launch a dedicated thread. If there is no other way, how do I create the thread and the queue where commands must be registered?
Thanks and regards, Juan _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
