Shared Memory Modules

S Green wrote:

Does any one now if a shared memory module exists, written in python
for a windows platform. I now one exists for unix?

Your first message with this same question did in fact make it to
Usenet and the mailing list.

Generally speaking, you should allow several days for answers to questions,
rather than getting anxious just because ten people don't jump up and answer
it in the first few hours.

(And my guess is that one doesn't exist, as Windows shared memory would
probably be a completely unreliable bitch, but that's just my guess. :-)

-Peter

st***********@baesystems.com (S Green) writes:

Does any one now if a shared memory module exists, written in python
for a windows platform. I now one exists for unix?
help most appreciated,

S Green

import mmap

Thomas Heller wrote:

st***********@baesystems.com (S Green) writes:

Does any one now if a shared memory module exists, written in python
for a windows platform. I now one exists for unix?
help most appreciated,

S Green

import mmap

The docs suggest that mmap.mmap(x, x, mmap.MAP_SHARED) will work under
Unix but not Windows.

Does the Windows version really support shared memory, or is the
multiple-maps-per-file feature only valid within a single process?

-Peter

Peter Hansen <pe***@engcorp.com> writes:

Thomas Heller wrote:

st***********@baesystems.com (S Green) writes:

> Does any one now if a shared memory module exists, written in python
> for a windows platform. I now one exists for unix?
>
>
> help most appreciated,
>
> S Green

import mmap

The docs suggest that mmap.mmap(x, x, mmap.MAP_SHARED) will work under
Unix but not Windows.

Does the Windows version really support shared memory, or is the
multiple-maps-per-file feature only valid within a single process?

Yes, it does. You have to give this memory block a name, though:

sharedmem = mmap.mmap(0, 16384, "GlobalSharedMemory")

This allows to access 16384 bytes of memory, shared across processes,
not backed up by a file in the filesystem.

Thomas

Thomas Heller wrote:

Peter Hansen <pe***@engcorp.com> writes:

Thomas Heller wrote:

st***********@baesystems.com (S Green) writes:

> Does any one now if a shared memory module exists, written in python
> for a windows platform. I now one exists for unix?
>
>
> help most appreciated,
>
> S Green

import mmap

The docs suggest that mmap.mmap(x, x, mmap.MAP_SHARED) will work under
Unix but not Windows.

Does the Windows version really support shared memory, or is the
multiple-maps-per-file feature only valid within a single process?

Yes, it does. You have to give this memory block a name, though:

sharedmem = mmap.mmap(0, 16384, "GlobalSharedMemory")

This allows to access 16384 bytes of memory, shared across processes,
not backed up by a file in the filesystem.

Thanks, Thomas.

In my opinion the documentation on this is entirely unclear. I attach
it for reference, but I can't offer any suggestions for improvement (as
I don't know anything about shared memory) except that even after reading
it a second time, Thomas' answer above is very much news to me:

'''tagname, if specified and not None, is a string giving a tag name
for the mapping. Windows allows you to have many different mappings
against the same file. If you specify the name of an existing tag,
that tag is opened, otherwise a new tag of this name is created. If
this parameter is omitted or None, the mapping is created without a
name. Avoiding the use of the tag parameter will assist in keeping your
code portable between Unix and Windows. '''

(from http://www.python.org/doc/current/lib/module-mmap.html)

-Peter

Thomas Heller wrote:

Does the Windows version really support shared memory, or is the
multiple-maps-per-file feature only valid within a single process?

Yes, it does. You have to give this memory block a name, though:

sharedmem = mmap.mmap(0, 16384, "GlobalSharedMemory")

This allows to access 16384 bytes of memory, shared across processes,
not backed up by a file in the filesystem.

That is très cool, it doesn't tell you this in the docs, does it?
The first argument is 'the file handle' of the file to be mapped,
and it doesn't say that 0 is valid and means 'no file at all'...

However, I've just tried it, and managed to crash Python in mmap.pyd
with an application exception... twice. But trying to reproduce it
now fails-- Python keeps running.
I did this:

import mmap
mem=mmap.mmap(0,3000000,'irmen')
mem[0]='a'
mem[2000000]='a'

and initially, it crashed......... Python 2.3.2 on win xp)

--Irmen

Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:

Thomas Heller wrote:

Does the Windows version really support shared memory, or is the
multiple-maps-per-file feature only valid within a single process?

Yes, it does. You have to give this memory block a name, though:
sharedmem = mmap.mmap(0, 16384, "GlobalSharedMemory")
This allows to access 16384 bytes of memory, shared across processes,
not backed up by a file in the filesystem.

That is très cool, it doesn't tell you this in the docs, does it?
The first argument is 'the file handle' of the file to be mapped,
and it doesn't say that 0 is valid and means 'no file at all'...

However, I've just tried it, and managed to crash Python in mmap.pyd
with an application exception... twice. But trying to reproduce it
now fails-- Python keeps running.
I did this:

>>> import mmap
>>> mem=mmap.mmap(0,3000000,'irmen')
>>> mem[0]='a'
>>> mem[2000000]='a'

and initially, it crashed......... Python 2.3.2 on win xp)

This works for me even from the beginning (with 2.3 CVS version, XP Pro).

Understading which parameters to pass apparently requires

- reading the mmapmodule.c sources
- and reading about CreateFileMapping and MapViewOfFile in MSDN.

It would be great if someine could submit a patch for the docs <wink>.

I vaguely remember, but am not able to find it anymore: didn't AMK once
had an article about this somewhere?

Thomas

Irmen de Jong wrote:

However, I've just tried it, and managed to crash Python in mmap.pyd
with an application exception... twice. But trying to reproduce it
now fails-- Python keeps running.
I did this:

>>> import mmap
>>> mem=mmap.mmap(0,3000000,'irmen')
>>> mem[0]='a'
>>> mem[2000000]='a'

and initially, it crashed......... Python 2.3.2 on win xp)
--Irmen

Probably not enough actual memory hanging around. Some systems
(and from this I'd guess XP) allocate virtual memory by reserving
address space, not actually allocating the RAM and/or backing
store for that memory. Python has no control over this, and you
have nothing good to do if the memory is over-allocated. When
you create the memory, you could walk across it writing into it
(forcing it to exist), but that would just force the failure to
happen earlier.
-Scott David Daniels
Sc***********@Acm.Org

Scott David Daniels wrote:

Irmen de Jong wrote:

However, I've just tried it, and managed to crash Python in mmap.pyd
with an application exception... twice. But trying to reproduce it
now fails-- Python keeps running.
I did this:

>>> import mmap
>>> mem=mmap.mmap(0,3000000,'irmen')
>>> mem[0]='a'
>>> mem[2000000]='a'

and initially, it crashed......... Python 2.3.2 on win xp)
--Irmen

Probably not enough actual memory hanging around. Some systems
(and from this I'd guess XP) allocate virtual memory by reserving
address space, not actually allocating the RAM and/or backing
store for that memory.

Over-commit is that called, right?
I'm sorry but that certainly wasn't the case here.
My machine has 512 Mb RAM and about 250 Mb of them
allocated when I tried it. (physical RAM that is)

Very weird, I cannot reproduce the initial crash I experienced.

--Irmen

On Tue, 02 Dec 2003 00:44:15 +0100, Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote:

Scott David Daniels wrote:

Irmen de Jong wrote:

However, I've just tried it, and managed to crash Python in mmap.pyd
with an application exception... twice. But trying to reproduce it
now fails-- Python keeps running.
I did this:
>>> import mmap
>>> mem=mmap.mmap(0,3000000,'irmen')
>>> mem[0]='a'
>>> mem[2000000]='a'
and initially, it crashed......... Python 2.3.2 on win xp)
--Irmen

Probably not enough actual memory hanging around. Some systems
(and from this I'd guess XP) allocate virtual memory by reserving
address space, not actually allocating the RAM and/or backing
store for that memory.

Over-commit is that called, right?
I'm sorry but that certainly wasn't the case here.
My machine has 512 Mb RAM and about 250 Mb of them
allocated when I tried it. (physical RAM that is)

Very weird, I cannot reproduce the initial crash I experienced.

What's that first zero argument?

Snip from mmap docs:
"""
mmap( fileno, length[, tagname[, access]])

(Windows version) Maps length bytes from the file specified by
the file handle fileno, and returns a mmap object. If length is 0,
the maximum length of the map will be the current size of the file
when mmap() is called.

tagname, if specified and not None, is a string giving a tag name
for the mapping. Windows allows you to have many different mappings
against the same file. If you specify the name of an existing tag,
that tag is opened, otherwise a new tag of this name is created.
If this parameter is omitted or None, the mapping is created without a name.
Avoiding the use of the tag parameter will assist in keeping your code portable
between Unix and Windows.
"""

Does that mean you are trying to use stdin as the open file handle?

Regards,
Bengt Richter

Bengt Richter wrote:

What's that first zero argument? [...] Does that mean you are trying to use stdin as the open file handle?

No it doesn't, according to Thomas Heller's post in this thread.
Thomas said 0 means "not associated with a file" on windows...

--Irmen

Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:

Bengt Richter wrote:

What's that first zero argument?

[...]

Does that mean you are trying to use stdin as the open file handle?

No it doesn't, according to Thomas Heller's post in this thread.
Thomas said 0 means "not associated with a file" on windows...

mmapmodule.c internally uses INVALID_HANDLE_VALUE of a file handle of 0
is used.

As I said, read the source (and MSDN). And then submit a documentation
patch <wink>.

Thomas

On Tue, 02 Dec 2003 10:54:19 +0100, Thomas Heller <th*****@python.net> wrote:

Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:

Bengt Richter wrote:

What's that first zero argument? [...]

Does that mean you are trying to use stdin as the open file handle?

No it doesn't, according to Thomas Heller's post in this thread.
Thomas said 0 means "not associated with a file" on windows...

mmapmodule.c internally uses INVALID_HANDLE_VALUE of a file handle of 0
is used.

Wouldn't passing None be more pythonic for a python interface?

As I said, read the source (and MSDN). And then submit a documentation
patch <wink>.

How does one do that? (being lazy, I guess I could find out via www.python.org)

Regards,
Bengt Richter

bo**@oz.net (Bengt Richter) writes:

On Tue, 02 Dec 2003 10:54:19 +0100, Thomas Heller <th*****@python.net> wrote:

Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes:

Bengt Richter wrote:
What's that first zero argument?
[...]
Does that mean you are trying to use stdin as the open file handle?

No it doesn't, according to Thomas Heller's post in this thread.
Thomas said 0 means "not associated with a file" on windows...

mmapmodule.c internally uses INVALID_HANDLE_VALUE of a file handle of 0
is used.

Wouldn't passing None be more pythonic for a python interface?

As I said, read the source (and MSDN). And then submit a documentation
patch <wink>.

How does one do that? (being lazy, I guess I could find out via www.python.org)

Finding out how to do this is the easier part ;-)

Ok, to get you started:

<http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/mmapmodule.c>
<http://msdn.microsoft.com/library/en-us/fileio/base/creating_named_shared_memory.asp>
<http://msdn.microsoft.com/library/en-us/fileio/base/createfilemapping.asp>
<http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp>

Thomas