[Unison-hackers] About the current OS X GUI hanging

[Trevor Jim]

>    - GUI thread calls OCaml to process a transfer instruction  
> (grabbing the lock)
>    - OCaml calls back to GUI to update the "done" information
>    - GUI thread needs to look up some bit of information from the  
> OCaml data structure to know how to update the screen, so it tries to  
> call back into OCaml, but now gets stuck because the lock is already  
> held

There are two issues, first is deadlock/starvation, second is crashing.

I think we crash because two objc threads call in to ocaml at the same
time.  We need more locking, as I indicated in my previous messages.

More locking of course will only increase the deadlock/starvation
problems.  Stepping back, what is going on is that while the ocaml
thread is running, the gui would like to be responsive, so there
should be communication between the ocaml thread and an objc gui
thread.  This communication **cannot** occur via the usual ocaml
C API, that's simply not allowed because of ocaml internal reasons.
Therefore simply adding reentrant locks or more locks (rather than
the one lock we have now) is not sufficient to handle the gui
responsiveness issue.

Therefore we need two things:
(1) More locking, so that there is only one call from objc through
     the ocaml C API at any given time
(2) A different mechanism to communicate between the ocaml thread
     and the objc gui thread.

For (2) the best solution that comes to mind is to allocate a buffer
in objc, allocate a mutex in objc, and lock the mutex in ocaml or
objc as needed to mediate access to the buffer, and communicate
using the buffer by some messages in some format.

-Trevor