Hi all,
just tried to use the module for ‘memory mapped files’ of Python 1.6b1 running
QRTP 2.1 beta (confrence CD, platform QNX6) … it doesn’t work.
Is there a way to map a file with mmap() into memory under QRTP 2.1??
(file descriptor created by fd = open(“FILE”) … not shm_open)
BTW … Python-1.6b1 compiles and works fine (+threads) under QRTP. It compiles
flawless under QNX4 … and terminates gracefully with a stack overflow 
Seems there are compiler problems again …
Regards
Armin
Armin Steinhoff wrote:
Hi all,
just tried to use the module for ‘memory mapped files’ of Python 1.6b1 running
QRTP 2.1 beta (confrence CD, platform QNX6) … it doesn’t work.Is there a way to map a file with mmap() into memory under QRTP 2.1??
(file descriptor created by fd = open(“FILE”) … not shm_open)
Hi Armin,
there is little undocumented trick - you should always add
MAP_NOSYNCFILE to flags, because current VM design doesn’t support
intermixed pointer/IO access. Which means you should also check if a
program really requires that (mixed write() and memory access). Most
programs don’t, but some might. Also, I’m not sure about QRTP but
earlier Augusta versions required MAP_ELF too, because historically they
implemented mmap()-ed files just to load shared object and libc always
checked that 
BTW … Python-1.6b1 compiles and works fine (+threads) under QRTP. It compiles
flawless under QNX4 … and terminates gracefully with a stack overflow >
Seems there are compiler problems again …
I don’t think that’s compiler issue. Looks more like libc problem to me.
In article <398E4621.79B1DE2E@home.com>, Igor says…
Armin Steinhoff wrote:
Hi all,
just tried to use the module for ‘memory mapped files’ of Python 1.6b1 running
QRTP 2.1 beta (confrence CD, platform QNX6) … it doesn’t work.Is there a way to map a file with mmap() into memory under QRTP 2.1??
(file descriptor created by fd = open(“FILE”) … not shm_open)
Hi Armin,
there is little undocumented trick - you should always add
MAP_NOSYNCFILE to flags, because current VM design doesn’t support
intermixed pointer/IO access. Which means you should also check if a
program really requires that (mixed write() and memory access).
Thanks … it needs simply write() access to a memory mapped file =:-/
Most
programs don’t, but some might. Also, I’m not sure about QRTP but
earlier Augusta versions required MAP_ELF too, because historically they
implemented mmap()-ed files just to load shared object and libc always
checked that >BTW … Python-1.6b1 compiles and works fine (+threads) under QRTP. It
compiles flawless under QNX4 … and terminates gracefully with a stack
overflow >
I don’t think that’s compiler issue. Looks more like libc problem to me.
You see an approach to solve that compiler/linker/libc problem ?
Do we have to give up with QNX4 ??
Regards
Armin
Armin Steinhoff wrote:
In article <> 398E4621.79B1DE2E@home.com> >, Igor says…
Armin Steinhoff wrote:
Hi all,
just tried to use the module for ‘memory mapped files’ of Python 1.6b1 running
QRTP 2.1 beta (confrence CD, platform QNX6) … it doesn’t work.Is there a way to map a file with mmap() into memory under QRTP 2.1??
(file descriptor created by fd = open(“FILE”) … not shm_open)
Hi Armin,
there is little undocumented trick - you should always add
MAP_NOSYNCFILE to flags, because current VM design doesn’t support
intermixed pointer/IO access. Which means you should also check if a
program really requires that (mixed write() and memory access).Thanks … it needs simply write() access to a memory mapped file =:-/
Huh, if it needed only write(), you could simply get rid of mmap()
altogether. Programs which do that assume that mmap() will speed up
access since write() could be optimized, but I doubt that will happen
given Neutrino’s VM design. Sebastien will correct me if I’m mistaken
BTW … Python-1.6b1 compiles and works fine (+threads) under QRTP. It
compiles flawless under QNX4 … and terminates gracefully with a stack
overflow >
I don’t think that’s compiler issue. Looks more like libc problem to me.You see an approach to solve that compiler/linker/libc problem ?
We’re talking about beta software. THE approach is to try to isolate
problem and narrow the cause. Then report bug. And when you do that
they usually give you quick fix to test and after few iterations it
usually works.
Do we have to give up with QNX4 ??
Hmm, that’s off-topic, but personally I gave up on it a while ago. Not
because it is bad, but because it is 10 years old and simply obsoleted
by NTO.
In article <398EDEC6.D68F3A61@motorola.com>, Igor says…
Armin Steinhoff wrote:
In article <> 398E4621.79B1DE2E@home.com> >, Igor says…
Armin Steinhoff wrote:
Hi all,
just tried to use the module for ‘memory mapped files’ of Python 1.6b1 running
QRTP 2.1 beta (confrence CD, platform QNX6) … it doesn’t work.Is there a way to map a file with mmap() into memory under QRTP 2.1??
(file descriptor created by fd = open(“FILE”) … not shm_open)
Hi Armin,
there is little undocumented trick - you should always add
MAP_NOSYNCFILE to flags, because current VM design doesn’t support
intermixed pointer/IO access. Which means you should also check if a
program really requires that (mixed write() and memory access).Thanks … it needs simply write() access to a memory mapped file =:-/
Huh, if it needed only write(), you could simply get rid of mmap()
altogether. Programs which do that assume that mmap() will speed up
access since write() could be optimized, but I doubt that will happen
given Neutrino’s VM design. Sebastien will correct me if I’m mistaken >
OK … memory mapped files are not supported with NTP (QRTP or what ever).
BTW … Python-1.6b1 compiles and works fine (+threads) under QRTP. It
compiles flawless under QNX4 … and terminates gracefully with a stack
overflow >
I don’t think that’s compiler issue. Looks more like libc problem to me.You see an approach to solve that compiler/linker/libc problem ?
We’re talking about beta software.
Hm … you mean the libc is beta software ??
The Pytthon 1.6b1 ‘beta software’ works flawless with NTO 2.1 …
THE approach is to try to isolate
problem and narrow the cause. Then report bug. And when you do that
they usually give you quick fix to test and after few iterations it
usually works.Do we have to give up with QNX4 ??
Hmm, that’s off-topic,
May be for you. ‘THE approach’ takes too much time … and I don’t believe that
QSSL will spend time for an non-commercial open source project to fix nitty
gritty details in their obsolete libc. So I give up to port Python 1.6b1 to
QNX4!
but personally I gave up on it a while ago. Not
because it is bad, but because it is 10 years old and simply obsoleted
by NTO.
I come just to the same conclusion …
Regards
Armin
- Igor
Armin Steinhoff wrote:
Huh, if it needed only write(), you could simply get rid of mmap()
altogether. Programs which do that assume that mmap() will speed up
access since write() could be optimized, but I doubt that will happen
given Neutrino’s VM design. Sebastien will correct me if I’m mistaken >OK … memory mapped files are not supported with NTP (QRTP or what ever).
That is too black & white picture Even in existing state of support
they are useful for many packages. Apache for example optimizes access
to static files trough mmap() and NTO’s implementation is just enough.
In fact for most applications MAP_NOSYNC is good thing and some newer
Unixes added it I believe.
We’re talking about beta software.
Hm … you mean the libc is beta software ??
The Pytthon 1.6b1 ‘beta software’ works flawless with NTO 2.1 …
THE approach is to try to isolate
problem and narrow the cause. Then report bug. And when you do that
they usually give you quick fix to test and after few iterations it
usually works.Do we have to give up with QNX4 ??
Hmm, that’s off-topic,
May be for you. ‘THE approach’ takes too much time … and I don’t believe that
QSSL will spend time for an non-commercial open source project to fix nitty
gritty details in their obsolete libc. So I give up to port Python 1.6b1 to
QNX4!
Sorry, I got confused. I thought in your original posting you were
talking about NTO. Now I see you was not.
In article <398F2A11.C802C0D2@motorola.com>, Igor says…
Armin Steinhoff wrote:
Huh, if it needed only write(), you could simply get rid of mmap()
altogether. Programs which do that assume that mmap() will speed up
access since write() could be optimized, but I doubt that will happen
given Neutrino’s VM design. Sebastien will correct me if I’m mistaken >OK … memory mapped files are not supported with NTP (QRTP or what ever).
That is too black & white picture >
http://www.unix-systems.org/onlinepubs/7908799 defines what’s black and white.
Even in existing state of support they are useful for many packages. Apache for
example optimizes access to static files trough mmap() and NTO’s implementation
is just enough.
I hate this ‘good enough’ approach if we deal with basic features.
With memory mapped files we could port open source data bases (Berkeley DB,
MySQL and others) just to overcome the lack of data base support for QRTP …
In fact for most applications MAP_NOSYNC is good thing and some newer
Unixes added it I believe.
I got confused … what is MAP_NOSYNC?? It’s not documented …
We’re talking about beta software.
Hm … you mean the libc is beta software ??
The Pytthon 1.6b1 ‘beta software’ works flawless with NTO 2.1 …
THE approach is to try to isolate
problem and narrow the cause. Then report bug. And when you do that
they usually give you quick fix to test and after few iterations it
usually works.Do we have to give up with QNX4 ??
Hmm, that’s off-topic,
May be for you. ‘THE approach’ takes too much time … and I don’t believe that
QSSL will spend time for an non-commercial open source project to fix nitty
gritty details in their obsolete libc. So I give up to port Python 1.6b1 to
QNX4!
Sorry, I got confused. I thought in your original posting you were
talking about NTO. Now I see you was not.
Here is my initial posting. It covers QRTP and QNX4 issues in the context of
Python 1.6b1. Sorry … I don’t know what’s confusing ??
:>Hi all,
:>just tried to use the module for ‘memory mapped files’ of Python 1.6b1 running
:>QRTP 2.1 beta (confrence CD, platform QNX6) … it doesn’t work.
:>Is there a way to map a file with mmap() into memory under QRTP 2.1??
:>(file descriptor created by fd = open(“FILE”) … not shm_open)
:>BTW … Python-1.6b1 compiles and works fine (+threads) under QRTP. It
:>compiles flawless under QNX4 … and terminates gracefully with a stack
:>overflow Seems there are compiler problems again …
Regards
Armin
Armin Steinhoff wrote:
I hate this ‘good enough’ approach if we deal with basic features.
It is not so basic. Full support for mmap() requires very
sophisticated VM model. That traditionally was outside of scope of
realtime OSes because being rarely needed for realtime applications it
implies considerable performance penalties.
That said, I’ve heard about plans to implement modern BSD-based VM for
Neutrino. So, keep banging their door Armin
With memory mapped files we could port open source data bases (Berkeley DB,
MySQL and others) just to overcome the lack of data base support for QRTP …
Some of them might work with current implementation too.
In fact for most applications MAP_NOSYNC is good thing and some newer
Unixes added it I believe.I got confused … what is MAP_NOSYNC?? It’s not documented …
I think it is FreeBSD name for MAP_NOSYNCFILE.
Here is my initial posting. It covers QRTP and QNX4 issues in the context of
Python 1.6b1. Sorry … I don’t know what’s confusing ??
It was just me confused, nothing is wrong with your posting.