[Paraview-developers] Client-Server MultiThread problem

[Utkarsh Ayachit]

John,

I am trying the think of clean solution for this. Is your server
mutli-threaded as well? Since you say "WaitForReady" blocks, without
server being multi-threaded, the ParaView GUI will also block the next
time it has to go to the server for anything, right?

The solution #2 you mentioned is also a totally reasonable approach.
You can use a QTimer with a timeout of 1sec or whatever you like and
then in the callback poll the server for "IsReadySignalPresent".

Utkarsh



On Mon, Apr 25, 2011 at 3:16 PM, Biddiscombe, John A. <biddisco at cscs.ch> wrote:
> Utkarsh
>
>>>
> What version of ParaView do you want to use for this?
> <<
>
> git HEAD onwards would be fine, I have no need to back port to 3.10, we used a timer to poll for new data in the past and it worked fine, but if we could remove the timer and instead notify the client directly , it'd clean things up.
>
> I see a longer reply from Pat which I will digest too.
>
> JB
>
> 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
>>
>