Hi John,<br><br>For some recent coprocessing work, I added a feature to my live-data branch that I called "client notify." It's just a second socket connection between client and server. Rather than try to push messages over the regular client-server control socket, I'm using an extra one. On the server side, when new data arrives, the filter sends a signal over the client notify socket. On the client side, I use QTcpSocket and QTcpServer. With these classes, you can attach callbacks to a waiting socket without messing with threads.<br>
<br>A while ago a pulled out the useful client-side socket code and put it into a stand alone plugin. I hope to find some free time soon to clean this up and put it on github. I think it satisfies a feature request that I see on the paraview mailing list quite often- a method for opening a control port on the paraview client so that an external process can control paraview.<br>
<br>My advice would be to avoid hijacking paraview's client-server stream, and use your own socket connection for control signals, OR investigate the new features brought in with the collaboration merge. That's not to say that you can't find a way to make the client-server stream work for you... I still have not had time to learn about the collab features, but I am hoping to have a meeting soon with Utkarsh or Sebastien so that I can get up to speed. The plan is that I will rewrite the communication layers in my live-data branch to take advantage of the new features, and this could be a model for the future.<br>
<br>Pat<br><br><br><div class="gmail_quote">On Mon, Apr 25, 2011 at 11:52 AM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
John,<br>
<br>
What version of ParaView do you want to use for this?<br>
<font color="#888888"><br>
Utkarsh<br>
</font><div><div></div><div class="h5"><br>
On Fri, Apr 22, 2011 at 8:11 AM, Biddiscombe, John A. <<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>> wrote:<br>
> We have tried to improve our steering/vis interface by adding a WaitCondition object to our server side objects so that when they have received data, a thread is awoken and signals the GUI to act.<br>
><br>
> Method one requires us the use of a special thread in the gui, which calls<br>
> proxy->InvokeCommand("WaitForReady")<br>
> this causes the client server stream handling code to invoke a method on the server which waits until completion and then returns. It works, but we have discovered that the client server stream (+ messaging) is not thread safe, so whilst we are waiting on that thread, if we use the same proxy object to send other commands, we get problems - the errors are actually quite specific to one particular scenario and I'll sip the details unless asked.<br>
><br>
> Previously, we got around this by simply using a timer in the GUI, which instead did<br>
> proxy->InvokeCommand("IsReadySignalPresent")<br>
> and this did not have two threads simultaneously using the same client server stream. The downside being that the timer was constantly running and we wanted to try a sleep condition.<br>
><br>
> Our ideal solution would be for the pvservers (which are hosting our data receive classes) to be able to emit a custom signal to the paraview client, using the standard mechanism used by the rest of paraview, to say that data has been received and we would like to do processing with it.<br>
><br>
> Is it possible to add a custom message into the core paraview message handling between client and server so that we can tell pvservers to send a "DSM data ready" message to the client, and then hook this to a callback in our plugin which will then take over and operate on the data using the normal channels? If so, can you point me to any code that does something similar so that I might tweak it (does coprocessing do anything similar anywhere?).<br>
><br>
> [I've glossed over some of the details here as we use one thread on the server for data/messaging and one on the client for triggering updates and the process is a bit more complex than described, but if we were able to tell pvserver to send a custom message, we could simplify things somewhat]<br>
><br>
> thanks<br>
><br>
> JB<br>
><br>
> --<br>
> John Biddiscombe, email:biddisco @ <a href="http://cscs.ch" target="_blank">cscs.ch</a><br>
> <a href="http://www.cscs.ch/" target="_blank">http://www.cscs.ch/</a><br>
> CSCS, Swiss National Supercomputing Centre | Tel: <a href="tel:%2B41%20%2891%29%20610.82.07" value="+41916108207">+41 (91) 610.82.07</a><br>
> Via Cantonale, 6928 Manno, Switzerland | Fax: <a href="tel:%2B41%20%2891%29%20610.82.82" value="+41916108282">+41 (91) 610.82.82</a><br>
><br>
> _______________________________________________<br>
> Paraview-developers mailing list<br>
> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
><br>
_______________________________________________<br>
Paraview-developers mailing list<br>
<a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
</div></div></blockquote></div><br>