[Paraview-developers] Client-Server MultiThread problem

Tue Apr 26 09:47:22 EDT 2011

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