On 7. May 2009, at 12:52, Juan Hernando (via Nabble) wrote:
> 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. Never ever call a blocking function from the receiver thread. Object mapping requires communication, and if you do this from the receiver thread you can no longer communicate. I know this is not documented properly. > 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 The session updates it's object map from the command thread. This is the reason you can't map objects from the command thread, since it would dead-lock. All this needs to get properly documented when making the eq::net API 'public'. > 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. Correct. The Barrier mapping happens from the pipe's render thread, not from the command thread. > > It's also true that the window commands are dispatched by the pipe > thread. Ah :) > 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? You can dispatch them to the node main thread. The node queue is processed continuously on render clients, and within certain functions, e.g., Config::frameFinish, on the application node. HTH, Stefan. -- View this message in context: http://n2.nabble.com/Threading-issues-in-command-dispatching-and-distributed-object-mapping.-tp2827266p2888516.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
_______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
