Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3C02AD85.50408@ece.gatech.edu>
Date: Mon, 26 Nov 2001 16:00:53 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Michael Haubenwallner <michael DOT haubenwallner AT salomon DOT at>
CC: cygwin AT cygwin DOT com
Subject: Re: cygipc-behaviour not like FreeBSD on destroying shmid
References: <3BFD0C18 DOT 1C0161D0 AT salomon DOT at>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Michael Haubenwallner wrote:


> I am using cygwin 1.3.4-1 at the moment with cygipc 1.10-1.
> 
> The problem i have is, that if all processes using shm are
> dead (nattch = 0) and the flag SHM_DEST is set in shm_perm.mode,
> the shm-entry does not disappear until calling ipcrm, so
> i can't start my application again.


That's bad... :-(

 
> My application is already working on many unixes
> (HP-UX/AIX/Linux/SunOS/ReliantUNIX), and now i also
> tested it successfully on FreeBSD.
> 
> So i checked the behaviour of shmctl(IPC_RMID) and shmdt(), in
> cooperation with fork() after shmat(), watching the output of
> ipcs on HP-UX, Linux and FreeBSD.
> 
> In short words my test does this:
> 
> *) Some tasks are using the same shm.
> *) one of these tasks says shmctl(IPC_RMID)
> *) on all systems this shmid is invalidated
> *) on HP-UX and Linux another task can create a new shm with same
>    key now while the old tasks can continue using their shm.
> *) on FreeBSD the shmid does not disappear until the last task using
>    it has shmdt()'d, but the key of this shmid is changed to zero
>    and a new task cannot create a new shm with this key.
> 
> Somewhere on cygwin's homepage i read that cygwin wants to be more
> like FreeBSD than Linux,


Errr...where did you see this?  AFAIK, Cygwin's policy is POSIX/SUSv2 
compliance where possible, and when those specs are ambiguous, try to be 
like linux.

So, what do the POSIX/SUSv2 specifications say about this case?  What is 
the specificiation behavior?

If you can demonstrate that POSIX or SUSv2 agree with the FreeBSD 
behavior, then I'll accept this patch, subject to testing by the 
postgresql community.  Otherwise, I'd prefer you rework the patch to 
mimic Linux behavior instead of FreeBSD.

> so i tried to modify to FreeBSD-behaviour
> (which i like more than the others in this special case) with attached
> patch.
> 
> Another problem might be that forking with attached shm does not
> increment the nattch-counter, but this is not really a problem
> for me and i suppose this might not be as simple as this one.


I *think* that would require special code in cygwin1.dll's fork() 
implementation.  Not gonna happen -- but...there is work going on to try 
to rewrite IPC support for cygwin.  Search the cygwin-developer archives 
for 'cygwin daemon'.


> Please can you check this patch, i can't really say if it affect's
> other applications using cygipc, especially postgresql (i found
> it often together with cygipc in the mailing-lists), since i am
> not yet using postgresql.


It looks okay, but I'd rather follow the Linux behavior unless SUSv2 or 
POSIX specs agree with BSD.


> Maybe you should remove the unneeded function killseg() in shm.c


No, although shmdt()'s call to killseq IS commented out, shmctl still 
calls it if IPC_RMIC && nattch <= 0 (except under your patch, which 
comments THAT call out as well --- in order to mimic FreeBSD behavior, 
AFAICT.)


> Thank you very much for reading this quite long mail!

Thanks for your analysis and patch.  Please investigate POSIX/SUSv2, and 
report back to the list.

Thanks,
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/