harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Dowdall <rdowd...@qnx.com>
Subject Re: [classlib] Shared Memory
Date Sun, 16 Sep 2007 02:29:10 GMT
Thanks Leo, this helps out.

Leo Li wrote:
>
> 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
>


Mime
View raw message