Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <072501c20fb8$8d16dc80$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: <cygwin-developers AT cygwin DOT com>
Subject: shm status
Date: Sun, 9 Jun 2002 14:21:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

In message http://cygwin.com/ml/cygwin-developers/2002-03/msg00000.html
"sysV IPC and SHM", Robert Collins announced the availability of an initial
cut of the sysv shm code in cygwin and provided a small test suite
(ipctest-0.1.2).

First, just to report that I've compiled and run the test suite (apparently
successfully) on my w2k box with the latest cvs cygwin. And I've also got
cygserver running all the time with no apparent problem.

Second, is anyone working actively on the shm implementation right now? I
was going to write some more test cases but, looking at the code, I notice
that it has the odd one or two FIXME comments, so I thought it might be
better to fix those first before trying to find any more issues.

Also the ipcs and ipcrm utitilities are really useful when working with sysv
ipc so I also thought I could start by adding these. Presumably this would
be a case for another cygwin_internal() interface? i.e. get the list of ids;
the program then issues xxxctl() calls to get the relevant details or rm the
requested objects. Any objections to such an approach? (Just for comparison,
the usual Un*x implementation involves reading kernel memory via /dev/kmem.)

// Conrad