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

[Kevin Ballard]

My inclination is to say a re-entrant lock is almost certainly what  
we want here. Are there any problems this could cause?

I haven't looked at the source. Is this callback happening on the  
main thread or on a separate thread? Because if it's happening on the  
main thread, then a re-entrant lock won't fix the problem, as the GUI  
is (or at least *should* be - if not, then this is a sleeping  
heisenbug waiting to trigger) on the main thread, and so any OCaml  
calls triggered from the GUI would be on a separate thread from the  
callback.

On Jan 23, 2007, at 9:21 AM, Benjamin Pierce wrote:

> Aha -- thanks, Alan!  That definitely helps.
>
> So it seems clear (without looking at the code, which I don't
> understand in any detail) that what's happening is:
>
>    - 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
>
> So I guess the next question is whether it is OK simply to release
> the lock when the callback happens (and re-acquire it on the
> recursive call to OCaml), or if this is not safe because it might
> lead to a *different* GUI thread acquiring the lock and making a call
> into OCaml instead.
>
> (I have a feeling it might not be safe: if there is a saved call
> stack on the OCaml side, then it seems like we need to return from
> callbacks in the order that they were made.  In which case we might
> fix the hang by making the lock re-entrant -- i.e., turning the lock
> into a counter and keeping track of the thread that is currently
> holding it.)
>
> Trevor?  Ben?

-- 
Kevin Ballard
http://kevin.sb.org
kevin at sb.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070123/de6547d0/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2432 bytes
Desc: not available
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20070123/de6547d0/smime-0001.p7s