I am attempting to write a pygtk application that spawns a number of
threads to access a GnomeVFS module for faster I/O. The GnomeVFS
module I am accessing is thread safe, but I am experiencing some odd
behavior with reads. First, when my threads would each try to read the
entire file at a time, the threads would proceed in the order they were
created, as if the actual read operation in the VFS was not causing a
context switch. I tried to test this by switching to only reading 4k
chunks at a time and then sleeping for a short tim and found that the
vfs reads were still happening without a context switch, python would
then switch on the sleep() call. Furthermore, there is a single lock
inside the VFS module that is locked and waited on with g_cond_wait().
However, when the module waits on the lock, the python module still
doesn't seem to context switch.
What I think may be happening is that the gnome-python GnomeVFS module
was created without calls to release/acquire the GIL. Thus, not only
do long-blocking IO's like reads and writes not get switched out, but
when the module attempts wait on the lock and puts the thread to sleep,
it still holds the GIL so that no other python threads can run. Does
this seem reasonable to people, or am I missing something obvious?
Anybody have any idea how hard it might be to implement the GIL inside
the gnome-python vfs module code?
Thanks!
- James
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
