[Paraview-developers] Client-Server MultiThread problem

Tue Apr 26 10:13:30 EDT 2011

Utkarsh,

ok thanks a lot, yes that would be even better if we do not have to open 
another socket connection. We wanted to have this all a bit more clean 
as soon as possible :) since we will have to write soon I think (don't 
know yet the deadline) an extended version of our EGPGV paper for TVCG. 
There is no specific deadline though for this work.

Thanks

Jerome

On 04/26/2011 03:53 PM, Utkarsh Ayachit wrote:
> 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
>>
>>
>>