Bug #5559
openServer push - concurrency issue
0%
Description
Hi!
We have a concurrency problem with UI-locks during server push operations:
We have a spawned thread that shows a modal dialog with a progressbar, builds our data model and pushes progressbar updates to the client UI.
It's quite similar to the example in your ServerPush.C
During this thread it is possible that another request for the same application becomes active, gains the UI-lock and modifies the data model.
This leads to a corrupted heap sometimes, when the two threads access the same data members.
Is there a possibility to get the UI-lock (before the auxiliary thread) and push changes without quiting the UI-lock?
I can extract a testcase showing our problem but this would take some time, maybe there is some quick help or hint from your side...
Best regards,
Max
Files
Updated by Roel Standaert about 7 years ago
- Status changed from New to Feedback
- Assignee set to Roel Standaert
I'm not sure I understand the situation completely. Whenever you want to change anything to the widget tree of a WApplication, or anything associated with it, like item models, you should take the update lock first.
Are you trying to change things without taking the update lock, or are you experiencing concurrency problems even when you have taken the update lock?
Regards,
Roel
Updated by Max Quatember about 7 years ago
Hi Roel!
My concurrency problem is:
During a server push in an auxiliary thread, between two UI locks, a new request for the same session on the main thread can become active and take the UI lock.
I would need to lock the UI for the whole time of a server-push and push multiple changes during one lock.
Is this clear enough?
Best regards,
Max
Updated by Roel Standaert about 7 years ago
There's no way to do this in Wt currently. You'd have to implement your own additional locking, or use a modal dialog to block events.
Updated by Max Quatember about 7 years ago
Hi Roel!
OK, I understand.
Our dialog that shows the progress is not modal. It is "show"n and not "exec"uted so it does not block the current request.
But If I "exec" the dialog, where is the place to start the auxiliary thread to server-push the progress?
We already tried to implement an additional locking, without success.
For me there are 2 ways to go on for now:
1) There is a way - that I don't know - to server-push changes from an auxiliary thread to a modal dialog.
2) You can implement us a way to do this in Wt.
Maybe we can also talk to Koen, he has a deeper insight in our application and history with Wt.
Best regards,
Max
Updated by Koen Deforche about 7 years ago
Hey max,
Modal and using exec() is not the same. A modal dialog simply prevents other events from being generated and handled until the dialog is closed. Exec() starts a recursive event loop (blocking the current thread) until the dialog is closed.
You can also have a modal dialog and show() it.
Regards,
Koen
Updated by Max Quatember about 7 years ago
Hi Koen!
Please excuse me, I confused myself.
We do "show" a "modal" dialog. Nevertheless we can force another event to get generated...
Best regards,
Max
Updated by Koen Deforche about 7 years ago
Hey Max,
You mean an event related to a widget from outside the dialog is being delivered? This shouldn't happen, it is actively being prevented within the session event handling. If so, then that's a bug.
Regards,
koen
Updated by Max Quatember about 7 years ago
Hi Koen!
Yes thats what I mean.
Post-mortem dumps from our customers show this situation.
We can reproduce the situation in about 1 of 100 cases.
For us its a minor but annoying problem - Beside the great performance and stability Wt delivers!
Our solution would be to globally get the UI-lock and push multiple updates during this UI-lock.
But this requires your help.
Best regards,
Max
Updated by Koen Deforche about 7 years ago
- Tracker changed from Support to Bug
Hey,
Can you provide some more detail of the direction to look into? Does the port-mortem indicate there is some kind of race condition in showing the dialog and having the signal, or something else?
Koen
Updated by Max Quatember about 7 years ago
Hi Koen!
I have a stacktrace of one of our crashes.
Thread 1:
Is the spawned thread after the modal dialog is shown.
Thread 2:
Is the concurrent request.
Is this enough information for you?
Max
Updated by Max Quatember over 6 years ago
Hi!
This can be closed, worked around this issue!
Best regards,
Max