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

[Benjamin Pierce]

Another thing to think about is whether these calls from the GUI into  
OCaml while an OCaml thread is already running are really needed --  
it may be that they are just looking up little bits of information  
that could just as easily be pre-fetched into C data structures in  
the main thread...

     - B


On Jan 23, 2007, at 3:32 PM, Trevor Jim wrote:

>>    - 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
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers