harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib] Shared Memory
Date Sat, 15 Sep 2007 07:27:46 GMT
On 9/15/07, Rodney Dowdall <rdowdall@qnx.com> wrote:
> Leo Li wrote:
> >
> > On 9/15/07, Rodney Dowdall <rdowdall@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

View raw message