Re: pyrenamer gives 'Attempt to unlock mutex that was not locked'
Hi all,
please find my approach to resolving the issue of "Attempt to unlock
mutex that was not locked" in the quoted emails below. The short answer
is that this error is caused by improper use of glib threading. Such
handling may have remained unnoticed up until now due to changes in the
recent glib (2.42). Debian unstable/testing has been migrating from
version 2.40 to 2.42 which is now causing this message in several codes.
Best regards
Torsten
-------- Original Message --------
Subject: Re: Threading in pdfshuffler
Date: Sun, 05 Oct 2014 22:19:40 +0200
From: Thilo <debian@matbox.de>
To: Jeremy Lainé
Hi Jeremy,
thanks for your immediate reply! I went deeper into this issue and found
the following:
A generally useful introduction and usage examples are given at [1].
However, GObject (Gdk3) and Gtk2 are not clearly distinguished and so
this does not provide a satisfying answer on how to proceed in the case
at hand.
Reference [2] gives practical guidelines on how one should write (new)
code. Keeping these in mind, the Gdk3 --and this is what we are using
when importing gobject as Kostas does in the code of pdfshuffler-
documentation gives further insight [3]:
> You should use gdk_threads_add_idle() and gdk_threads_add_timeout() instead of g_idle_add() and g_timeout_add() since libraries not under your control might be using the deprecated GDK locking mechanism. If you are sure that none of the code in your application and libraries use the deprecated gdk_threads_enter() or gdk_threads_leave() methods, then you can safely use g_idle_add() and g_timeout_add().
Considering that the original author (Kostas) already utilizes GObject
by means of function calls such as "gobject.idle_add()" instead of
"gdk_threads_add_idle()", I think that we are better off to entirely
remove the deprecated calls to "gtk.gdk.threads_init()" and related
functions.
Regarding your changes in the "update_thumbnail" method, I support your
view.
I uploaded an updated version of the code at [4] (I updated
"changelog.debian", too). However, as I am still trying to understand
Debian packaging I haven't created a package yet.
I see two possibilities of how to proceed right now: (i) you could grab
the files
* pdfshuffler/pdfshuffler.py and
* changelog.debian
and build a new package or (ii) you wait for me packaging it and
possibly answer some questions on the procedure in the meantime.. ;-)
Feel free to forward this email to the PAPT-list. I haven't joined yet
and since reportbug is broken as well, I don't feel like submitting the
bug report myself at the moment..
Best regards
Torsten
[1] https://wiki.gnome.org/Projects/PyGObject/Threading
[2] http://stackoverflow.com/a/21156816/3043824
[3] https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
[4] https://github.com/fuesika/pdfshuffler-ng
On 05.10.2014 10:09, Jeremy Lainé wrote:
> Hi Torsten,
>
> I won't pretend I am a GTK expert - I most certainly am not, I am
> usually a Qt person - so it was basically trial and error, up-to-date
> GTK on the topic are pretty confusing. I basically drew inspiration from
> the bug report against "reportbug" which suffered from the same startup
> error. I had not considered your option for the main loop which seems
> even better since it avoids calls to the deprecated methods.
>
> I still believe the gdk_threads_enter/leave can be removed in the
> "update_thumbnail" method as we are not actually calling any GDK code here.
>
> Cheers,
> Jeremy
>
> On 10/05/2014 02:40 AM, fuesika wrote:
>> Dear Jeremy,
>>
>> please find an e-mail below that I sent to the original author
>> pdfshuffler. I was working on a bugfix at the time that you provided it
>> via the repositories. Thanks for submitting!
>>
>> Looking at the source, I am still wondering what the originally intended
>> threading behavior is (no answer from Kostas, yet).
>> While my approach entirely removed the (explicit) gtk2-threading --could
>> and should remove the gobject/gtk3-threading as well if I understand the
>> glib-documentation correctly-- you set the entire program up as a
>> threads-section which prevents any multi-threading.
>>
>> I am still trying to fully grasp the threading of glib and this is the
>> reason why I am writing to you. What are the reasons for your approach?
>> Aren't the commands "gtk.gdf.threads_init()" et al. obsolete since glib
>> 2.22?
>>
>> Best regards
>> Torsten
>>
>>
>> -------- Original Message --------
>> Subject: Threading in pdfshuffler
>> Date: Fri, 03 Oct 2014 14:51:33 +0200
>> To: Kostas
>>
>> Dear Kostas,
>>
>> through a Debian update a few minutes ago, I became of the (partly
>> deprecated) threading lines in the code pdf-shuffler. The version from
>> sourceforge states
>>> def main():
>>> """This function starts PdfShuffler"""
>>> gtk.gdk.threads_init()
>>> gobject.threads_init()
>>> PdfShuffler()
>>> gtk.main()
>> What I though that is appropriate (removing the multi-threading):
>>> def main():
>>> """This function starts PdfShuffler"""
>>> gobject.threads_init()
>>> PdfShuffler()
>>> gtk.main()
>> What the Debian-guys made of it:
>>> def main():
>>> """This function starts PdfShuffler"""
>>> gtk.gdk.threads_init()
>>> gtk.gdk.threads_enter()
>>> PdfShuffler()
>>> gtk.main()
>>> gtk.gdk.threads_leave()
>> Moreover they removed the "threads_enter/_leave" from "update_thumbnail()".
>>
>> After all, the Debian update made pdfshuffler start again (but so does
>> my patch).
>>
>> Is the threading a critical issue, e.g. in creating the thumbnails? I
>> cannot fully comprehend how gdk-threading works, yet. From what I
>> understand, threading has been reorganized [1] and there is no more need
>> for initialization. Therefore, the lines in the Debian-code are
>> superfluent and could be removed as well?!
>> The line "gobject.threads_init()" should be removed as well, because it
>> refers to Gtk3, which is not used in pdfshuffler. It even requires gtk2:
>>> pygtk.require('2.0')
>> I hope we can work this out so that I can prepare a patch for the
>> gtk2-version in debian before it breaks due to removal of the deprecated
>> threading-statements. Secondly, this may be helpful for setting up a
>> proper threading in the new gtk3-based version.
>>
>> Best regards
>> Torsten
>>
>> [1] https://wiki.gnome.org/Projects/PyGObject/Threading
>
>
Reply to: