/Please file a bug report. This should not happen. Can you provide the following in the bug report?
Ideally: A patch to reproduce the problem in eqPly or a unit test Otherwise: - What type of objects (unbuffered, delta, ...) are you using? - Which Equalizer version or git revision? - Using the simplest configuration and '--eq-logfile', attach the logs with EQ_LOG_LEVEL=INFO for all processes (sanitize them for host names, if needed) and gdb 'thread apply all bt' from the process having the master instances (application, I guess). / I would. But I"m sure I'm doing something wrong. I'm attempting to map objects on the render node side and I request the config using getConfig(). This returns the same pointer as the config on the application(server / whatever you call the node that loads the config file) side. This can't be right. I'm almost positive the problem isn't with Equalizer but with something stupid I'm doing. I'm looking at eqPly. I've configured it such that I run one instance as a client and listening on localhost:2002. Then I run another instance which loads a config file that connects to that client. Now, VertexBufferDist is registering and mapping. I can't figure out what is causing getInstanceData and applyInstanceData to be called. I understand that there are some packets being sent. I see that objectStore.cpp has a _cmdMapObject() function which I believe is handling the mapping from master to slave - somehow. But again, I'm not sure how this is happening. I've checked the programmer's guide and it doesn't really make it any clearer to me. I'm pretty sure that what you are doing with mapping the vertexBufferDist is exactly what I need to do. Where are the commands being sent in eqPly which cause the vertexBufferDists to be mapped? I just can't seem to pinpoint it. /> Then, on the Distributable side, the Distributable queues itself up to be processed by a worker thread (with shared contexts, etc...). This worker thread then syncs() the Distributable and processes the work. Is there one worker thread or multiple? Seems like multiple from your description below. / There are multiple worker threads. Each render node has it's own worker thread pool. Cheers, Stefan. -- View this message in context: http://software.1713.n2.nabble.com/Sending-packets-containing-std-wstring-tp6845178p6949166.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
