[Paraview-developers] Client-Server MultiThread problem

Tue Apr 26 09:53:11 EDT 2011

Jerome,

Let me try to create a simple sample plugin to demonstrate the
capability. What Pat suggested is indeed a viable alternative. But I
think it should be possible to do what you want without having to open
a new socket connection. Let me prototype it a bit so I'll have a
clear understanding myself. What is your deadline for this?

Utkarsh

On Tue, Apr 26, 2011 at 9:47 AM, Jerome Soumagne <soumagne at cscs.ch> wrote:
> Utkarsh,
>
> thanks.
>
> yes the server is multi-threaded but the "WaitForReady" (which blocks using
> condition variable functions) is called in the main thread. The second
> server thread (called "service thread"), when it receives new data, sends a
> signal to this main server thread (I simplify but that's the idea). So yes
> in effect, the ParaView GUI would block next time it has to go to the server
> if we use the current implementation that we have. So clearly I can see now
> that waiting in the server would not be the ideal solution... unless we use
> another thread ? but that sounds a bit messy.
>
> Having also read Pat's response, it sounds like the best solution would be
> to open another socket port and make use of QTcpSocket so that we could send
> a signal from our server "service thread" directly to the ParaView GUI
> thread (not the main GUI thread but a QThread specially created to handle
> this operation). But would this not interfere with any other ParaView
> client/server messaging? even if use another port?
> Actually in that case we would no longer have to use the "WaitForReady" call
> on the server, but use a blocking receive in the client QThread. And the
> server would no longer block. I'm not sure yet if I like this solution but
> it would allow us to send a message from the "service thread" directly back
> to the GUI.
>
> The solution #2 is the solution we initially implemented, in that case the
> "service thread" sets a server flag "IsReadySignalPresent" and the client
> QTimer regularly does an InvokeCommand of "GetIsReadySignalPresent". This
> works, but as John explained, we thought it was not that good to have this
> timer constantly running.
>
> Jerome
>
> On 04/26/2011 02:17 PM, Utkarsh Ayachit wrote:
>>
>> 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
>>>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
> --
> Jérôme Soumagne
> Scientific Computing Research Group
> CSCS, Swiss National Supercomputing Centre
> Galleria 2, Via Cantonale  | Tel: +41 (0)91 610 8258
> CH-6928 Manno, Switzerland | Fax: +41 (0)91 610 8282
>
>
>