[Patches] [ python-Patches-708374 ] add offset to mmap
SourceForge.net
noreply at sourceforge.net
Sat Oct 28 23:54:54 CEST 2006
Patches item #708374, was opened at 2003-03-23 06:33
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: add offset to mmap
Initial Comment:
This patch is from Yotam Medini <yotamm at
mellanox.co.il> sent to me in mail.
It adds support for the offset parameter to mmap.
It ignores the check for mmap size "if the file is
character device. Some device drivers (which I happen
to use) have zero size in fstat buffer, but still one
can seek() read() and tell()."
I added minimal doc and tests.
----------------------------------------------------------------------
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-28 14:54
Message:
Logged In: YES
user_id=341410
Right. The question that Martin had was if you have some
mmap that has been mapped some offset into the large file,
and you do mmap.find(...), do you return an offset relative
to the file on disk, or relative to the mmap?
So if I have m = mmap.mmap(..., startoffset=1024,
length=1024), and I do m.find('X'), do I get some value
-1...1023 inclusive (-1 for not found), or do I get some
value 1024...2047 or -1? I think it only makes sense to
return -1...1023, so that the return for .find() and other
operations are relative to the mmap, not the file.
----------------------------------------------------------------------
Comment By: Yotam Medini (yotam)
Date: 2006-10-28 14:46
Message:
Logged In: YES
user_id=22624
I am not sure I am following all arguments.
But a major motivation for having an offset parameter,
is to allow for mapping a segment of a huge file.
A file could have a size which is too large for memory mapping.
But one may need to map just a 'small' segment
of a well known offset address.
By the way, my experience in this case was in Linux only.
----------------------------------------------------------------------
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-28 11:29
Message:
Logged In: YES
user_id=341410
I agree. In the majority of use-cases that I would
consider, offset into the current mmap object would be more
useful than into the file. If the mmap has information
about its offset in the file, then the user could easily get
the file offset.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2006-10-28 11:12
Message:
Logged In: YES
user_id=21627
I have update the patch (mmap3.diff) for the current trunk
(52498).
I've reviewed and tested the Windows implementation, and found
the original patch to be incorrect: For MapViewOfFile,
instead of
passing the size, offset+size must be passed. I also extended it
to support 64-bit offsets on a 64-bit system (64-bit offsets on
a 32-bit system still aren't supported).
I have doubts about the changes to find and tell: why is it
good that it includes the offset? In particular, for find,
I think it should return the index in the buffer, not the
offset in the file.
----------------------------------------------------------------------
Comment By: Yotam Medini (yotam)
Date: 2003-12-08 11:01
Message:
Logged In: YES
user_id=22624
Recent posts deal mainly about with size checks against
stat() call.
But the main issue here is the support for offset in mmap()ping.
I wonder what is the status of this so
it would become part of the official release.
If nobody cares to implement and test it for MS-Windows,
let's have it for Linux/Unix only.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2003-07-15 06:07
Message:
Logged In: YES
user_id=11375
The device driver check is now committed to CVS, both the
trunk and 2.2 maintenance branch.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2003-07-14 13:02
Message:
Logged In: YES
user_id=11375
According to my reading of the Single Unix Specification
page for sys/stat.h,
st_size only has a sensible value for regular files and for
symlinks. This implies that the size comparison should only
be done if S_ISREG() returns true. Patch attached as
mmap_reg.diff; I'll also check it in after running the tests.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2003-07-11 06:54
Message:
Logged In: YES
user_id=11375
There's nothing to test on Windows; the HAVE_FSTAT code is
inside #ifdef UNIX. If it works on Unix (and it seems to
for me, on Linux), then it should be checked in.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-26 20:19
Message:
Logged In: YES
user_id=33168
Yes, the check for block devices should go in now as a bug
fix I think. Can anyone test on windows? I attached a
patch for just this minimal change.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2003-06-26 10:05
Message:
Logged In: YES
user_id=11375
Shouldn't block devices also be excluded from the size check?
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-05 07:59
Message:
Logged In: YES
user_id=33168
Since this is an enhancement, it will not go into 2.2.x.
The patch is stuck right now. It needs to be tested on
Windows, but I can't do that (no Windows development
environment). If you can update the patch to work on both
Unix and Windows, we can apply the patch.
----------------------------------------------------------------------
Comment By: Yotam Medini (yotam)
Date: 2003-06-05 07:55
Message:
Logged In: YES
user_id=22624
Just wondering, what is the status of this patch.
I guess it did not make it to 2.2.3.
regards -- yotam
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-22 20:53
Message:
Logged In: YES
user_id=80475
This is much closer and solves the last problem.
But, it fails test_mmap with a windows errocode 8: not
enought memory.
Raymond
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-10 11:20
Message:
Logged In: YES
user_id=33168
http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true
says the offset must be a multiple of the allocation
granularity which used to be hard-coded at 64k. So maybe if
we made the offset 64k it would work. The attached patch
makes this test change for windows only. (I think the Unix
offset must be a multiple of PAGESIZE.)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-10 10:53
Message:
Logged In: YES
user_id=80475
I had posted the wrong traceback (before the rebuild).
The correct one shows Window Error #87.
Traceback (most recent call last):
File "test_mmap.py", line 357, in ?
test_main()
File "test_mmap.py", line 353, in test_main
test_offset()
File "test_mmap.py", line 37, in test_offset
m = mmap.mmap(f.fileno(), mapsize - PAGESIZE,
offset=PAGESIZE)
WindowsError: [Errno 87] The parameter is incorrect
[9363 refs]
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-10 10:14
Message:
Logged In: YES
user_id=33168
Note to self: Self, make sure to backport S_ISCHR() fix.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-10 10:10
Message:
Logged In: YES
user_id=33168
Hmmm, did Modules/mmapmodule.c get rebuilt? There is code
in the patch for new_mmap_object() to support the offset
keyword in both Unix & Windows. I don't see a problem in
the code/patch.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-10 09:01
Message:
Logged In: YES
user_id=80475
It doesn't run:
C:\py23\Lib\test>python_d test_mmap.py
Traceback (most recent call last):
File "test_mmap.py", line 357, in ?
test_main()
File "test_mmap.py", line 353, in test_main
test_offset()
File "test_mmap.py", line 37, in test_offset
m = mmap.mmap(f.fileno(), mapsize - PAGESIZE,
offset=PAGESIZE)
TypeError: 'offset' is an invalid keyword argument for this
function
[9363 refs]
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-09 16:35
Message:
Logged In: YES
user_id=33168
Raymond, could you try to test this patch and see if it
works on Windows?
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-29 13:28
Message:
Logged In: YES
user_id=33168
Sounds fair. Attached is an updated patch which includes
windows support (I think). I cannot test on Windows.
Tested on Linux. Includes updates for doc, src, and test.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-03-27 16:12
Message:
Logged In: YES
user_id=21627
I think non-zero offsets need to be supported for Windows as
well.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-23 07:37
Message:
Logged In: YES
user_id=33168
Email received from Yotam:
I have downloaded and patched the 2.3a source. compiled
locally just this module, and it worked fine for my
application (with offset for character device file) I did
not run the released test though.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470
More information about the Patches
mailing list