Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 60187 invoked from network); 16 Sep 2007 02:29:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Sep 2007 02:29:51 -0000 Received: (qmail 83206 invoked by uid 500); 16 Sep 2007 02:29:42 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 83170 invoked by uid 500); 16 Sep 2007 02:29:42 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 83161 invoked by uid 99); 16 Sep 2007 02:29:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Sep 2007 19:29:42 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [209.226.137.76] (HELO nimbus.ott.qnx.com) (209.226.137.76) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Sep 2007 02:29:40 +0000 Received: from [192.168.20.139] (192.168.20.139 [192.168.20.139]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S8GGRSV5; Sat, 15 Sep 2007 22:29:18 -0400 Message-ID: <46EC94F6.5050701@qnx.com> Date: Sat, 15 Sep 2007 22:29:10 -0400 From: Rodney Dowdall User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: Re: [classlib] Shared Memory References: <46EB6526.8050501@qnx.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Thanks Leo, this helps out. Leo Li wrote: > > On 9/15/07, Rodney Dowdall wrote: > > Leo Li wrote: > > > > > > On 9/15/07, Rodney Dowdall 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 >