You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Rodney Dowdall <rd...@qnx.com> on 2007/09/14 21:00:51 UTC
[classlib] Shared Memory
Hello
Please forgive my ignorance, but I am not certain on how the Unix
shmget, shmat, shmdt functions work. I am trying to port the classlib
to QNX Neutrino, which uses shm_open, shm_ctl and shm_unlink. In the
shared memory code a control file is created, and then a key is
generated using ftok with the control file name. Control file data is
then written to the control file. When you do a shmat is the shared
memory attaching to the file? Or is it a clean area in memory? I'm
wondering if I have to generate a new name for my shm_open call, or if I
can just use the control file name.
Thanks,
Rodney
Re: [classlib] Shared Memory
Posted by Rodney Dowdall <rd...@qnx.com>.
Thanks Leo, this helps out.
Leo Li wrote:
>
> On 9/15/07, Rodney Dowdall <rd...@qnx.com> wrote:
> > Leo Li wrote:
> > >
> > > On 9/15/07, Rodney Dowdall <rd...@qnx.com> wrote:
> > >
> > > > Hello
> > > >
> > > > Please forgive my ignorance, but I am not certain on how the Unix
> > > > shmget, shmat, shmdt functions work. I am trying to port the
> classlib
> > > > to QNX Neutrino, which uses shm_open, shm_ctl and shm_unlink.
> In the
> > > > shared memory code a control file is created, and then a key is
> > > > generated using ftok with the control file name. Control file
> data is
> > > > then written to the control file. When you do a shmat is the
> shared
> > >
> > > Hi, Rodney:
> > >
> > > Excuse me, are you trying to use a shared memory file as the
> control
> > > file?
> > >
> > No. I wanted to know the behaviour of the ftok function and whether
> the
> > key that it generates based off of the filename and the ID is linked to
> > the file on disk in any way.
> >
> > > > memory attaching to the file? Or is it a clean area in memory?
> I'm
> > >
> > > If you transfer a NULL parameter as the target address for shmat,
> > > System will choose a proper block( and not allocated ) of virtual
> > > memory space into which the shared memory will be mapped.
> > >
> > I don't have the shmat function on QNX. Only shm_open, shm_unlink, and
> > shm_ctl. I'm trying to provide the same functionality of the current
> > shared memory functions in the harmony classlib, but I have to use
> > different calls. I'm trying to make sure that the behaviour is
> consistent.
>
> In my opinion, shm_open is a good candidate for hyshmem_open, but
> hyshmem_open has a side-effect from the code: If the name specified as
> that of the shared memory is not an existing file, such a file will be
> created under HYSH_BASEDIR.
> Although it will be a little difficult to replace shmat, in
> hyshmem, shmat is only reference by shmaddr as NULL, which means that
> system will select the mapped virtual memory block and is compatible
> with the behavior of shmem_open.
>
> >
> > > > wondering if I have to generate a new name for my shm_open call, or
> > > if I
> > > > can just use the control file name.
> > >
> > > If you want shm_open to get different shared memory objects,
> it is
> > > necessary to use distinct names. Although shm_open will return
> > > different fid by the same name, the fid will reference the same
> shared
> > > memory objects. Furthermore, the shared object is system wide and
> will
> > > last till next boot or explicitly call shm_unlink if I have not
> missed
> > > something
> > >
> > But is that what the shared memory routines in hyshmem.c in the portlib
> > want to have happen? It has a control file name and it creates a key
> > using that control file name and an ID of 1. The ID never changes.
> > Does the control file name change? Based on your comments if I
> shm_open
> > the control file, that would probably be a bad thing. I assume that
> the
> > control file is not shared between processes.
>
> The control file name derived from the "rootname" parameter of the
> hyshmem_open which identifies a specified shared memory object. I
> think, in this way, the memory object can be shared among processes by
> the its name.:)
>
> >
> > Thanks,
> > Rodney
> >
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>
Re: [classlib] Shared Memory
Posted by Leo Li <li...@gmail.com>.
On 9/15/07, Rodney Dowdall <rd...@qnx.com> wrote:
> Leo Li wrote:
> >
> > On 9/15/07, Rodney Dowdall <rd...@qnx.com> wrote:
> >
> > > Hello
> > >
> > > Please forgive my ignorance, but I am not certain on how the Unix
> > > shmget, shmat, shmdt functions work. I am trying to port the classlib
> > > to QNX Neutrino, which uses shm_open, shm_ctl and shm_unlink. In the
> > > shared memory code a control file is created, and then a key is
> > > generated using ftok with the control file name. Control file data is
> > > then written to the control file. When you do a shmat is the shared
> >
> > Hi, Rodney:
> >
> > Excuse me, are you trying to use a shared memory file as the control
> > file?
> >
> No. I wanted to know the behaviour of the ftok function and whether the
> key that it generates based off of the filename and the ID is linked to
> the file on disk in any way.
>
> > > memory attaching to the file? Or is it a clean area in memory? I'm
> >
> > If you transfer a NULL parameter as the target address for shmat,
> > System will choose a proper block( and not allocated ) of virtual
> > memory space into which the shared memory will be mapped.
> >
> I don't have the shmat function on QNX. Only shm_open, shm_unlink, and
> shm_ctl. I'm trying to provide the same functionality of the current
> shared memory functions in the harmony classlib, but I have to use
> different calls. I'm trying to make sure that the behaviour is consistent.
In my opinion, shm_open is a good candidate for hyshmem_open, but
hyshmem_open has a side-effect from the code: If the name specified as
that of the shared memory is not an existing file, such a file will be
created under HYSH_BASEDIR.
Although it will be a little difficult to replace shmat, in
hyshmem, shmat is only reference by shmaddr as NULL, which means that
system will select the mapped virtual memory block and is compatible
with the behavior of shmem_open.
>
> > > wondering if I have to generate a new name for my shm_open call, or
> > if I
> > > can just use the control file name.
> >
> > If you want shm_open to get different shared memory objects, it is
> > necessary to use distinct names. Although shm_open will return
> > different fid by the same name, the fid will reference the same shared
> > memory objects. Furthermore, the shared object is system wide and will
> > last till next boot or explicitly call shm_unlink if I have not missed
> > something
> >
> But is that what the shared memory routines in hyshmem.c in the portlib
> want to have happen? It has a control file name and it creates a key
> using that control file name and an ID of 1. The ID never changes.
> Does the control file name change? Based on your comments if I shm_open
> the control file, that would probably be a bad thing. I assume that the
> control file is not shared between processes.
The control file name derived from the "rootname" parameter of the
hyshmem_open which identifies a specified shared memory object. I
think, in this way, the memory object can be shared among processes by
the its name.:)
>
> Thanks,
> Rodney
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib] Shared Memory
Posted by Rodney Dowdall <rd...@qnx.com>.
Leo Li wrote:
>
> On 9/15/07, Rodney Dowdall <rd...@qnx.com> wrote:
>
> > Hello
> >
> > Please forgive my ignorance, but I am not certain on how the Unix
> > shmget, shmat, shmdt functions work. I am trying to port the classlib
> > to QNX Neutrino, which uses shm_open, shm_ctl and shm_unlink. In the
> > shared memory code a control file is created, and then a key is
> > generated using ftok with the control file name. Control file data is
> > then written to the control file. When you do a shmat is the shared
>
> Hi, Rodney:
>
> Excuse me, are you trying to use a shared memory file as the control
> file?
>
No. I wanted to know the behaviour of the ftok function and whether the
key that it generates based off of the filename and the ID is linked to
the file on disk in any way.
> > memory attaching to the file? Or is it a clean area in memory? I'm
>
> If you transfer a NULL parameter as the target address for shmat,
> System will choose a proper block( and not allocated ) of virtual
> memory space into which the shared memory will be mapped.
>
I don't have the shmat function on QNX. Only shm_open, shm_unlink, and
shm_ctl. I'm trying to provide the same functionality of the current
shared memory functions in the harmony classlib, but I have to use
different calls. I'm trying to make sure that the behaviour is consistent.
> > wondering if I have to generate a new name for my shm_open call, or
> if I
> > can just use the control file name.
>
> If you want shm_open to get different shared memory objects, it is
> necessary to use distinct names. Although shm_open will return
> different fid by the same name, the fid will reference the same shared
> memory objects. Furthermore, the shared object is system wide and will
> last till next boot or explicitly call shm_unlink if I have not missed
> something
>
But is that what the shared memory routines in hyshmem.c in the portlib
want to have happen? It has a control file name and it creates a key
using that control file name and an ID of 1. The ID never changes.
Does the control file name change? Based on your comments if I shm_open
the control file, that would probably be a bad thing. I assume that the
control file is not shared between processes.
Thanks,
Rodney
Re: [classlib] Shared Memory
Posted by Leo Li <li...@gmail.com>.
On 9/15/07, Rodney Dowdall <rd...@qnx.com> wrote:
> Hello
>
> Please forgive my ignorance, but I am not certain on how the Unix
> shmget, shmat, shmdt functions work. I am trying to port the classlib
> to QNX Neutrino, which uses shm_open, shm_ctl and shm_unlink. In the
> shared memory code a control file is created, and then a key is
> generated using ftok with the control file name. Control file data is
> then written to the control file. When you do a shmat is the shared
Hi, Rodney:
Excuse me, are you trying to use a shared memory file as the control file?
> memory attaching to the file? Or is it a clean area in memory? I'm
If you transfer a NULL parameter as the target address for shmat,
System will choose a proper block( and not allocated ) of virtual
memory space into which the shared memory will be mapped.
> wondering if I have to generate a new name for my shm_open call, or if I
> can just use the control file name.
If you want shm_open to get different shared memory objects, it is
necessary to use distinct names. Although shm_open will return
different fid by the same name, the fid will reference the same shared
memory objects. Furthermore, the shared object is system wide and will
last till next boot or explicitly call shm_unlink if I have not missed
something.
>
> Thanks,
> Rodney
>
--
Leo Li
China Software Development Lab, IBM