I’m currently working on supporting abort in ParaView and in that context I had to understand the client/server communication protocol, which is virtually undocumented even in developer docs.
So I decided to share my findings here and also share how I will actually adress aborting a filter in client/server mode.
Please note this is not the same as supporting asynchronous UI, which is another thing entirely, but is a step in that direction.
What happens when you press apply in client/server mode and there is no progress events:
CLIENT SERVER
│ ┌─┐
│ │││
│ │││Receive()
┌┴┐ ExecuteStream("UpdatePipeline") │││
Send()│├├──────────────────────────────────────────►└─┘
└┬┘ ┌─┐
┌┴┐ │││
Send()│├├───────────────────────┐ │││
└┬┘ │ │││
┌─┐ │ │││
│││ │ │││
│││ │ │││
│││ │ │││UpdatePipeline()
│││ ExecuteStream("CleanupPendingProgress") │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ └─┘
│││ └───────────────────►│
│││ ┌─┐
│││ │││Cleanup()
│││ └─┘
Receive()│││ CLEANUP_TAG ┌─┐
│││◄──────────────────────────────────────────┼┤│Send()
└─┘ └─┘
As you can see, while the server is actually processing the data and doing the computation, the client is already trying to receive the CLEANUP_TAG, and waits in that state until the server is sending it.
With ProgressEvent in between, here is how it looks:
CLIENT SERVER
│ ┌─┐
│ │││
│ │││Receive()
┌┴┐ ExecuteStream("UpdatePipeline") │││
Send()│├├──────────────────────────────────────────►└─┘
└┬┘ ┌─┐
┌┴┐ │││
Send()│├├───────────────────────┐ │││
└┬┘ │ │││
┌─┐ │ │││
│││ │ │││
│││ │ │││
│││ │ │││UpdatePipeline()
│││ │ │││
Receive()│││ │ │││
OnWrongTagEvent │││ PROGRESS_TAG 0.33 │││
┌───────────────────────┐◄──│┘│◄──────────────────────┼───────────────────┼┤│
│ RefreshProgress(0.33) │ │ │ │ │││
└───────────────────────┴───►┐│ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
OnWrongTagEvent Receive()│││ PROGRESS_TAG 0.66 │││
┌───────────────────────┐◄──│┘│◄──────────────────────┬───────────────────┼┤│
│ RefreshProgress(0.66) │ │ │ │ │││
└───────────────────────┴───►┐│ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ ExecuteStream("CleanupPendingProgress") │││
│││ │ │││
│││ │ │││
│││ │ │││
│││ │ └─┘
│││ └───────────────────►│
│││ ┌─┐
│││ │││Cleanup()
│││ └─┘
Receive()│││ CLEANUP_TAG ┌─┐
│││◄──────────────────────────────────────────┼┤│Send()
└─┘ └─┘
As you can see, the magic here is the OnWrongTagEvent Logic that let CLIENT receive the wrong message and execute code in reaction, before resuming the receive wait.
Given all of that, how do you fit a Abort logic in there.
For starters, we must stop the client for starting the cleanup progress stuff right away but instead wait for the completion of the pipeline before the cleanup.
Second we need a way for the client to inform the server that Abort was triggered.
Adding a bidrectionnel OnWrongTagEvent may be possible but at this point an actual event queue would be prefferable and that is way too complex to set that up.
However, I can simply flag a proxy as aborted on client side and when processing a progress event, informing the server that a specific proxy have been aborted.
Here is how it looks:
CLIENT SERVER
│ ┌─┐
│ │││
│ │││Receive()
┌┴┐ ExecuteStream("UpdatePipeline") │││
Send()│├├──────────────────────────────────────────►└─┘
└─┘ ┌┬┐
┌─┐ │││
│││ │││
│││ │││
│││ │││UpdatePipeline()
│││ │││
Receive()│││ │││
OnWrongTagEvent │││ PROGRESS_T 0.33 │││
┌───────────────────────┐◄──│┘│◄──────────────────────────────────────────┼┤│
│ RefreshProgress(0.33) │ │ │ ABORT FALSE │││
└───────────────────────┴───►┌┼──────────────────────────────────────────►│││
│││ │││
│││ │││
│││ │││
│││ │││
│││ │││
│││ │││
OnWrongTagEvent Receive()│││ PROGRESS_T 0.66 │││
┌───────────────────────┐◄──│┘│◄──────────────────────────────────────────┼┤│
│ RefreshProgress(0.66) │ │ │ │││
TriggerAbort()────────►│ Abort = true; │ │ │ ABORT TRUE │││
└───────────────────────┴───►┌┼──────────────────────────────────────────►│││
│││ └─┘
Receive()│││ STREAM_EXECUTED_TAG ┌┬┐
│││◄──────────────────────────────────────────┼┤│Send()
└┴┘ └┴┘
┌┬┐ ExecuteStream("CleanupPendingProgress") │
│├┼──────────────────────────────────────────►┌┼┐
Send()│││ │││
└┴┘ │││Cleanup()
┌┬┐ └─┘
│││ CLEANUP_TAG ┌─┐
Receive()│││◄──────────────────────────────────────────┼┤│Send()
│││ └─┘
└─┘
By waiting for Receive(STREAM_EXECUTED_TAG), I ensure the socket stays free of clutter and can be used by the client to send a ABORT information back.
The triggerAbort() is a bit tricky and can be done thanks to Qt letting us input event during the RefreshProgress call, but improving this is a whole other subject.
I do not look specifcally for feedback here, but if you have any, feel free!