Re: locking foo ...

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