[Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX

[SourceForge.net]

Bugs item #678250, was opened at 2003-01-31 18:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: test_mmap failling on AIX

Initial Comment:
test_mmap is failing on a flush while trying to do:
  Copy-on-write memory map data not written correctly

The problem is that the mmap is opened with 
ACCESS_COPY.  This translates to MAP_PRIVATE.  
On AIX, the msync man page says:  "When the 
MS_SYNC and MAP_PRIVATE flags both are used, the 
msync subroutine returns an errno value of EINVAL."

I'm not sure what the correct fix should be.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-05-03 12:09

Message:
Logged In: YES 
user_id=21627

The documentation for flush says

"Flushes changes made to the in-memory copy of a file back
to disk."

But it doesn't do that, and we all agree it shouldn't do
that. So I would claim that it is an error to use .flush on
an mmap object that was opened in ACCESS_COPY. 

This is like trying to write to a file that was opened for
reading only: one *could* declare that the write just does
nothing, but it helps the developer more if you get an
exception, because the code is likely wrong (i.e. not
following the likely intentions of the author).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 21:55

Message:
Logged In: YES 
user_id=31435

Sorry, I've had nothing to do with mmap beyond fixing bugs.  
The "access" feature was due to Jay Miller, although I believe 
I checked in his patch.

Martin, I don't understand why you think it's reasonable for 
flush to complain here:  the mmap is open for writing, so 
what's surprising about expecting to be able to flush after a 
write?  Simply that there's no associated file, due to copy-on-
write?  Then user code would have to be acutely aware of how 
an mmap'ed object was opened, just to avoid nuisance 
complaints when they flush after writing.

So that's a third alternative:  alter the implementation to make 
mmap.flush() do nothing when an mmap object was opened 
as copy-on-write.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-04 08:00

Message:
Logged In: YES 
user_id=21627

I think the test is somewhat bogus: It tries to check that
modification to an ACCESS_COPY doesn't modify the underlying
file, but assumes that .flush becomes a no-op, even though
an exception is more reasonable (IMO; errors should never
pass silently).

So I see two options: Declare that .flush() always raises an
exception (and modify implementations that don't produce an
exception accordingly), or declare that aspect to be
system-dependent, and modify the test (and the
documentation) to expect and ignore an exception.

Assigning to Tim, as he incorporated that feature into mmap.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470