public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Michael Haubenwallner <michael.haubenwallner@salomon.at>
To: egcs@cygnus.com
Cc: cygwin@cygwin.com
Subject: cygipc-behaviour not like FreeBSD on destroying shmid
Date: Thu, 22 Nov 2001 06:31:00 -0000	[thread overview]
Message-ID: <3BFD0C18.1C0161D0@salomon.at> (raw)
Message-ID: <20011122063100.L_I6oSrgkvO01Mj7vmrxSFBWcNt8BGmiqJtZoIL8xkQ@z> (raw)

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.haubenwallner@salomon.at     http://www.salomon.at
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");	


             reply	other threads:[~2001-11-22  6:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-15  1:03 Michael Haubenwallner [this message]
2001-11-16  3:36 ` Charles Wilson
2001-11-16  5:26   ` Robert Collins
2001-11-26 14:36     ` Robert Collins
2001-11-26 13:00   ` Charles Wilson
2001-11-22  6:31 ` Michael Haubenwallner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BFD0C18.1C0161D0@salomon.at \
    --to=michael.haubenwallner@salomon.at \
    --cc=cygwin@cygwin.com \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).