Thanks Leo, this helps out.
Leo Li wrote:
On 9/15/07, Rodney Dowdall <[EMAIL PROTECTED]> wrote:
> Leo Li wrote:
> >
> > On 9/15/07, Rodney Dowdall <[EMAIL PROTECTED]> 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
