[issue1572968] release GIL while doing I/O operations in the mmap module
Charles-Francois Natali
report at bugs.python.org
Tue Apr 6 13:20:41 CEST 2010
Charles-Francois Natali <neologix at free.fr> added the comment:
As soon as you're dealing with files (not anonymous mapping), you can get the same type of latency than when using open/read/write...
While it's probably not worth the trouble to release the GIL for every operation involving mmaped-files, there are a couple places where it should be considered, for example:
Modules/mmapmodule.c:new_mmap_object
#ifdef HAVE_FSTAT
# ifdef __VMS
/* on OpenVMS we must ensure that all bytes are written to the file */
if (fd != -1) {
fsync(fd);
}
# endif
fsync() can take up to a couple seconds, so we should probably allow threads here (this is done only on VMS).
Another place worth looking at is when using msync(), like in mmap_object_dealloc():
if (m_obj->data!=NULL) {
msync(m_obj->data, m_obj->size, MS_SYNC);
munmap(m_obj->data, m_obj->size);
}
or in mmap_flush_method():
if (-1 == msync(self->data + offset, size, MS_SYNC)) {
PyErr_SetFromErrno(mmap_module_error);
return NULL;
}
msycn too can take quite a long time to complete.
I can write a patch if someone's willing to review it.
----------
nosy: +neologix
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1572968>
_______________________________________
More information about the Python-bugs-list
mailing list