Charles-Francois Natali <neolo...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue1572968>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
