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

[SourceForge.net]

Bugs item #678250, was opened at 2003-01-31 12:44
Message generated for change (Comment added) made by tim_one
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: Martin v. Löwis (loewis)
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: Tim Peters (tim_one)
Date: 2003-04-28 15: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 02: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