Please see bug #569772 for a demonstration of this. I think it might actually be a dupe of this bug, but I am not sure.

*** Bug 569772 has been marked as a duplicate of this bug. ***

Any chance this fix (releasing the locks) could get into the next stable release? The current limitation makes GIO effectively useless for transferring large files

Ping? I think this a quite a serious limitation...

This bug is quite easy to fix; you just need to add pyg_unblock_threads() / pyg_block_threads() around the C function call that may take time to execute.  For example:

Index: gio/gio.override
===================================================================
--- gio/gio.override	(revision 1003)
+++ gio/gio.override	(working copy)
@@ -289,11 +289,13 @@
 
     pygio_notify_reference_callback(notify);
 
+    pyg_unblock_threads();
     g_drive_eject(G_DRIVE(self->obj),
 		  flags,
 		  cancellable,
 		  (GAsyncReadyCallback) async_result_callback_marshal,
 		  notify);
+    pyg_block_threads();
 
     Py_INCREF(Py_None);
     return Py_None;


For functions that are not overridden in a .override file, you need to add (unblock-threads #t) to the def, example:

Index: gio/gio.defs
===================================================================
--- gio/gio.defs	(revision 1003)
+++ gio/gio.defs	(working copy)
@@ -994,6 +994,7 @@
    "result of the operation.")
   (c-name "g_drive_eject")
   (return-type "none")
+  (unblock-threads #t)
   (parameters
     '("GMountUnmountFlags" "flags" (default "G_MOUNT_UNMOUNT_NONE"))
     '("GCancellable*" "cancellable" (null-ok) (default "NULL"))

Hope this helps.

Created attachment 128737 [details] [review]
patch adding threads unblock

I don't know if I got them all, if some are missing let me know, or better update the patch :)

Gian: this is a case where any level of completeness is better than current state.  Please go ahead and commit your patch.

I just tested this (uninstalled) using the attached test case. Im not sure if this was a bug in my setup, but the main loop is still stalled throughout the copy process. Can someone else please run the test case and see if they agree?

Created attachment 128801 [details]
Test if main loop is blocked

Should be installed in the tests directory, and run from there. The expected output is a constant sequence of printed '.'s but instead I see nothing printed during the file_copy process - indicating that the mainloop is stalled.

See bug #569772 for another test case comparing the behaviour with GnomeVfs

I've committed the patch but I'll leave the bug open as per John's comments.

Were you able to see the behaviour I described when you ran the test case? It could just be a problem on my system.

Created attachment 128873 [details]
Test if mainloop is blocked

Updated test case to only use the newly built gobject and gio. Still exhibits the same bug.

copy into tests/runtests2.py

run with

python tests/runtests2.py

Sorry this was my fault for giving bad information.  I was confusing pyg_block/unblock_threads with pyg_beging/end_allow_threads :P

I fixed it in trunk.  Sorry.

And for future reference, to support threading with wrapping blocking C APIs you should use:

...
pyg_begin_allow_threads;
call_the_c_function();
pyg_end_allow_threads;

For async callbacks, in the past there was pyg_block_threads and pyg_unblock_threads (wrapping similarly named Python C API functions).  The problem with pyg_block_threads is that it only works if the current thread does *not* already hold the python interpreter lock.

Once PEP 311 (in Python 2.3), a new API, gil_state_ensure, gil_state_release, was introduced that avoids the problem above.  So, for all intents and purposes, we could already consider block/unblock threads as deprecated.

> Sorry this was my fault for giving bad information.  I was confusing
> pyg_block/unblock_threads with pyg_beging/end_allow_threads :P
> 
> I fixed it in trunk.  Sorry.
> 

Ok that is good to hear. Do you also need to revert the multiple addition of

+  (unblock-threads #t)

In the gio.defs file?

Any chance you could also apply this fix to the current stable branch?

(In reply to comment #15)
> > Sorry this was my fault for giving bad information.  I was confusing
> > pyg_block/unblock_threads with pyg_beging/end_allow_threads :P
> > 
> > I fixed it in trunk.  Sorry.
> > 
> 
> Ok that is good to hear. Do you also need to revert the multiple addition of
> 
> +  (unblock-threads #t)

No, that part is still correct.  The generated code from that is correct.

> 
> In the gio.defs file?
> 
> Any chance you could also apply this fix to the current stable branch?
> 

Not me; ask Gian? :D

> > Ok that is good to hear. Do you also need to revert the multiple addition of
> > 
> > +  (unblock-threads #t)
> 
> No, that part is still correct.  The generated code from that is correct.

Oh OK, so it is just a matter of confusing naming.

> 
> > 
> > In the gio.defs file?
> > 
> > Any chance you could also apply this fix to the current stable branch?
> > 
> 
> Not me; ask Gian? :D
> 

Ok, I am re-opening this bug then. No offence intended.

Gian et. al please close this again if there is no possibility of applying this fix to stable branch, or if you do not intend to make any more releases from that branch (which would obviously make applying the patch pointless).

(In reply to comment #17)

> Gian et. al please close this again if there is no possibility of applying this
> fix to stable branch, or if you do not intend to make any more releases from
> that branch (which would obviously make applying the patch pointless).

It's going to be hell but yes, I'm going to backport the bug fixes into 2.16 branch and make a new release. 

Fixed in stable branch too.