[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-09-18 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: Any thoughts on this? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-04-08 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- nosy: +akuchling, exarkun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-04-08 Thread Charles-Francois Natali
Changes by Charles-Francois Natali : Added file: http://bugs.python.org/file16828/test_mmap.py ___ Python tracker ___ ___ Python-bugs-list mail

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-04-08 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: Alright, the current behaviour is quite strange: we don't call msync() when closing the object, we just unmap() it: mmap_close_method(mmap_object *self, PyObject *unused) { [...] #ifdef UNIX if (0 <= self->fd) (void) close(self->

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-04-06 Thread Charles-Francois Natali
Charles-Francois Natali added the comment: I don't think that calling msync() or FlushViewOfFile() when closing the mmap object or deallocating it is a good idea. sync()ing dirtied pages to disk is very expensive, blocks the process for a long time, and the OS does a much better job at it (it

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-01-12 Thread Antoine Pitrou
Antoine Pitrou added the comment: A test could explicitly close a dirtied mmaped file and then open() it to check that everything was written, no? -- nosy: +pitrou ___ Python tracker __

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-01-12 Thread Brian Curtin
Brian Curtin added the comment: tab/space issue, updated the patch -- Added file: http://bugs.python.org/file15839/issue2643.diff ___ Python tracker ___ _

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-01-12 Thread Brian Curtin
Changes by Brian Curtin : Removed file: http://bugs.python.org/file15838/issue2643.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2010-01-12 Thread Brian Curtin
Brian Curtin added the comment: Added the FlushViewOfFile calls, and an msync call to the close method. Not sure how to explicitly test this, if it's possible. Current tests pass on Windows, I'll need to check *NIX when I have the access later today. As for justification, from the UnmapViewOf

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2008-04-17 Thread Trent Nelson
Changes by Trent Nelson <[EMAIL PROTECTED]>: -- nosy: +Trent.Nelson __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubsc

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2008-04-16 Thread Ralf Schmitt
Ralf Schmitt <[EMAIL PROTECTED]> added the comment: The close method does not call msync or FlushViewOfFile. I find this a bit strange cause explicitly closing the mmap will not flush changes but relying on the garbage collector will flush changes. __ Tracker <[EM

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2008-04-16 Thread Ralf Schmitt
Changes by Ralf Schmitt <[EMAIL PROTECTED]>: -- type: -> behavior versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue2643] mmap_object_dealloc does not call FlushViewOfFile on windows

2008-04-16 Thread Ralf Schmitt
New submission from Ralf Schmitt <[EMAIL PROTECTED]>: on unix it does call msync however. here is the relevant part from mmapmodule.c: static void mmap_object_dealloc(mmap_object *m_obj) { #ifdef MS_WINDOWS if (m_obj->data != NULL) UnmapViewOfFile (m_obj->data);