cygipc-behaviour not like FreeBSD on destroying shmid

cygipc-behaviour not like FreeBSD on destroying shmid

[Michael Haubenwallner]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

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

[-- Attachment #2: cygipc-1.10-patch --]
[-- Type: text/plain, Size: 1167 bytes --]

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");	



[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
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/

Re: cygipc-behaviour not like FreeBSD on destroying shmid

[Charles Wilson]

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/

Re: cygipc-behaviour not like FreeBSD on destroying shmid

[Robert Collins]

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> > 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'.

Chuck, you can use pthread_atfork() to have a function called in your
app when fork () is called. You could call that during shmattach, and
then when you callback is triggered increment nattch..

Rob


--
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/

cygipc-behaviour not like FreeBSD on destroying shmid

[Michael Haubenwallner]

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");	

Re: cygipc-behaviour not like FreeBSD on destroying shmid

[Charles Wilson]

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/

Re: cygipc-behaviour not like FreeBSD on destroying shmid

[Robert Collins]

----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> > 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'.

Chuck, you can use pthread_atfork() to have a function called in your
app when fork () is called. You could call that during shmattach, and
then when you callback is triggered increment nattch..

Rob


--
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/