GNOME Bugzilla – Bug 314085
GtkClipboardGetFunc () called with main gtk lock held (needs callback to provide data)
Last modified: 2014-03-24 02:48:22 UTC
While adding gtk clipboard/selection support to GNU Classpath (awt.datatransfer) there was one issue that makes integration possibly deadlock when GtkClipboardGetFunc () is called. When the GtkClipboardGetFunc () callback is called it is expected that the data is transformed and provided in the requested target format immediately. But we might have to call arbitrary user code for providing the requested format that might need other gtk+ functions (our awt implementation is also based on gtk+). Since we are holding the main gtk lock while GtkClipboardGetFunc () is called we cannot call back into any gtk function because we would risk deadlock. A way to provide a callback or other notification method that can be called to provide the actual data to put on the clipboard is needed to make it possible to use gtk+ functions to provide actual target that is requested by GtkClipboardGetFunc (). See also the following thread: http://lists.gnu.org/archive/html/classpath-patches/2005-08/msg00243.html
So, my personal view is that if you feel the need to lock around every gtk call, you should bite the bullet and make the lock recursive. But since that is considered a non-solution, let me also state that we'd rather not see an async-on-async api added for this, but rather audit the code in gtkselection.c and gtkclipboard.c to make sure that it is safe to drop the lock in the callback.
closing out ancient bugs