Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3BFD0C18.1C0161D0@salomon.at> Date: Thu, 22 Nov 2001 15:30:48 +0100 From: Michael Haubenwallner X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: de-AT, en MIME-Version: 1.0 CC: cygwin AT cygwin DOT com Subject: cygipc-behaviour not like FreeBSD on destroying shmid Content-Type: multipart/mixed; boundary="------------869063A8DF63AA66371AB1AF" X-Virus-Scanned: by AMaViS perl-11 --------------869063A8DF63AA66371AB1AF Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Hello Chuck! 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. 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, 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. 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. Maybe you should remove the unneeded function killseg() in shm.c Thank you very much for reading this quite long mail! -- haubi Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz T +43 3127 200 308 T +43 3127 200 mailto:michael DOT haubenwallner AT salomon DOT at http://www.salomon.at --------------869063A8DF63AA66371AB1AF Content-Type: text/plain; charset=iso-8859-15; name="cygipc-1.10-patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cygipc-1.10-patch" diff -ru cygipc-1.10/ipc-daemon.c cygipc/ipc-daemon.c --- cygipc-1.10/ipc-daemon.c Thu Nov 22 14:21:13 2001 +++ cygipc/ipc-daemon.c Thu Nov 22 14:21:30 2001 @@ -390,14 +390,13 @@ } } } /* for (Index ... ) */ -/* - if( Index == SHMMNI ) - { + if( Index == SHMMNI + && (LAdrShm->shm[id].shm_perm.mode | SHM_DEST) == SHM_DEST + ) { LAdrShm->shm[id].shm_perm.seq++; LAdrShm->shm_seq = (LAdrShm->shm_seq+1) % ((unsigned)(1<<31)/SHMMNI); LAdrShm->shm_segs[id] = (struct shmid_ds *) IPC_UNUSED; } -*/ } } /* for (id ... ) */ diff -ru cygipc-1.10/shm.c cygipc/shm.c --- cygipc-1.10/shm.c Thu Nov 22 14:21:14 2001 +++ cygipc/shm.c Thu Nov 22 14:23:32 2001 @@ -471,10 +471,13 @@ CYGWIN_IPCNT_RETURN_DECONNECT ( -EPERM ) ; case IPC_RMID: shp->shm_perm.mode |= SHM_DEST; + shp->shm_perm.key = 0; +/* if (shp->shm_nattch <= 0) { killseg (id); } +*/ break; default: debug_printf("shmctl : return -EINVAL\n"); --------------869063A8DF63AA66371AB1AF Content-Type: text/plain; charset=us-ascii -- 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/ --------------869063A8DF63AA66371AB1AF--