[Paraview-developers] Client-Server MultiThread problem

[pat marion]

Hi John,

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.

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.

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.

Pat


On Mon, Apr 25, 2011 at 11:52 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> John,
>
> What version of ParaView do you want to use for this?
>
> Utkarsh
>
> On Fri, Apr 22, 2011 at 8:11 AM, Biddiscombe, John A. <biddisco at cscs.ch>
> wrote:
> > 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.
> >
> > Method one requires us the use of a special thread in the gui, which
> calls
> >  proxy->InvokeCommand("WaitForReady")
> > 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.
> >
> > Previously, we got around this by simply using a timer in the GUI, which
> instead did
> >  proxy->InvokeCommand("IsReadySignalPresent")
> > 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.
> >
> > 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.
> >
> > 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?).
> >
> > [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]
> >
> > thanks
> >
> > JB
> >
> > --
> > John Biddiscombe,                            email:biddisco @ cscs.ch
> > http://www.cscs.ch/
> > CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
> > Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
> >
> > _______________________________________________
> > Paraview-developers mailing list
> > Paraview-developers at paraview.org
> > http://public.kitware.com/mailman/listinfo/paraview-developers
> >
> _______________________________________________
> Paraview-developers mailing list
> Paraview-developers at paraview.org
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20110425/72b2fe5a/attachment.htm>