This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients josiahcarlson, luks, neologix, pitrou
Date 2010-04-06.11:20:40
SpamBayes Score 1.552898e-07
Marked as misclassified No
Message-id <1270552841.96.0.0746486216743.issue1572968@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-04-06 11:20:42neologixsetrecipients: + neologix, josiahcarlson, pitrou, luks
2010-04-06 11:20:41neologixsetmessageid: <1270552841.96.0.0746486216743.issue1572968@psf.upfronthosting.co.za>
2010-04-06 11:20:40neologixlinkissue1572968 messages
2010-04-06 11:20:40neologixcreate