On 2013-12-04 14:36, Stephan Bergmann wrote:
On 12/04/2013 01:13 PM, Noel Grandin wrote:
(*) Change the UNO/scripting processing model to do something like
while (Message m = readMessage() != null) {
invokeOnMainThread(void f() {
processMessage(m);
});
}
...which deadlocks as soon as you have a synchronous call chain -> A -> B -> C where A and C are local and B is a
callback to the remote site.
I have very little hopes that any "automatic" scheme will bring success here. The only model that would IMO work is
to have a single-threaded GUI (as virtually everybody else does too, for a reason), in the one direction offloading
potentially time-consuming activities triggered by the GUI event loop to additional threads, and in the other
direction dispatching GUI activities required by non-GUI code (e.g., URP, scripting) to the GUI event loop, explicitly
coded.
I think we're mostly talking about the same solution (i.e. single-threaded GUI).
Personally I think we should we ban the kind of synchronous call chain you specify above, but if we absolutely have to
support it, it can still fit into my suggestion using something like (not my idea, copied from other message pump
architectures I have seen) :
void sendMessageAndWaitForReply(Message m) {
sendToSocketAsynchronous(m); // very important, don't want to block here if
the socket buffer is full
if (running on main thread) {
while (true) {
waitForMainThreadAndSocket();
if (wokenUpBecauseOfMainThread()) {
processAnyEventsFromMainThread();
}
if (wokenUpBecauseOfSocket()) {
processIncomingMessageFromSocket();
break;
}
}
} else {
waitForSocket();
processIncomingMessageFromSocket();
}
}
i.e. run a subsidiary message pump.
Disclaimer: http://www.peralex.com/disclaimer.html
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
