Thread: darwin pgsql patches
Here are patches to CVS top of tree that allow darwin to completely
build and install. Unfortunately, the sem...() shim does not function
correctly yet, so it's not stable enough to use. With luck I'll be able to
get it working before 7.1 goes final. But the addition of these patches
and new files is a big step towards support for Mac OS X. (Please make sure
that the Makefile patches have tabs in the correct locations.)
Questions or comments to pmb@mac.com please.
Thanks!
-pmb
new directory:
src/backend/port/darwin/
===================================================================
new file:
src/backend/port/darwin/Makefile
===================================================================
#-------------------------------------------------------------------------
#
# Makefile--
# Makefile for port/darwin
#
# IDENTIFICATION
# $Header: $
#
#-------------------------------------------------------------------------
subdir = src/backend/port/darwin
top_builddir = ../../../..
include $(top_builddir)/src/Makefile.global
OBJS = sem.o
all: SUBSYS.o autotestsem
SUBSYS.o: $(OBJS)
$(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS)
autotestsem: autotestsem.o sem.o
$(CC) -o autotestsem sem.o autotestsem.o
depend dep:
$(CC) -MM $(CFLAGS) *.c >depend
clean:
rm -f SUBSYS.o $(OBJS) autotestsem autotestsem.o
ifeq (depend,$(wildcard depend))
include depend
endif
===================================================================
new file:
src/backend/port/darwin/autotestsem.c
===================================================================
/*-------------------------------------------------------------------------
*
* autotestsem.c
* Test of System V Semaphore Emulation
*
* Copyright (c) 2000, Peter Bierman
*
* IDENTIFICATION
* $Header: $
*
*-------------------------------------------------------------------------
*/
/* placeholder file for a self-test program I plan to write. pmb-001128 */
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "postgres.h"
#include "storage/ipc.h"
#include <sys/mman.h>
#include "sem.h"
int
main(int argc, char **argv)
{
return 0;
}
===================================================================
new file:
src/backend/port/darwin/sem.c
instructions:
cp src/backend/port/qnx4/sem.c src/backend/port/darwin/sem.c
then apply patch:
===================================================================
--- ../qnx4/sem.c Wed Apr 12 10:15:30 2000
+++ sem.c Tue Nov 28 22:40:40 2000
@@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
- * $Header: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/qnx4/sem.c,v 1.3 2000/04/12 17:15:30 momjian Exp
$
+ * $Header: $
*
*-------------------------------------------------------------------------
*/
@@ -22,11 +22,12 @@
#include "postgres.h"
#include "storage/ipc.h"
#include "storage/proc.h"
-#include <sys/sem.h>
+//#include <sys/sem.h>
+#include "sem.h"
-#define SETMAX ((MAXBACKENDS + PROC_NSEMS_PER_SET - 1) / PROC_NSEMS_PER_SET)
-#define SEMMAX (PROC_NSEMS_PER_SET)
+#define SEMMAX (IPC_NMAXSEM)
+#define SETMAX ((MAXBACKENDS + SEMMAX - 1) / SEMMAX)
#define OPMAX 8
#define MODE 0700
@@ -135,6 +136,9 @@
if (nsems < 0 || nsems > SEMMAX)
{
+#ifdef DEBUG_IPC
+ fprintf(stderr, "darwin semget aborting because nsems out of range. (%d)\n", nsems);
+#endif
errno = EINVAL;
return -1;
}
@@ -152,7 +156,7 @@
if (fd == -1)
return fd;
/* The size may only be set once. Ignore errors. */
- ltrunc(fd, sizeof(struct sem_info), SEEK_SET);
+ ftruncate(fd, sizeof(struct sem_info));
SemInfo = mmap(NULL, sizeof(struct sem_info),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (SemInfo == MAP_FAILED)
@@ -196,6 +200,10 @@
{
if (nsems != 0 && SemInfo->set[semid].nsems < nsems)
{
+#ifdef DEBUG_IPC
+fprintf(stderr, "darwin: semget failed because if (nsems != 0 && SemInfo->set[semid].nsems < nsems) %d %d\n",
+ nsems, SemInfo->set[semid].nsems);
+#endif
sem_post(&SemInfo->sem);
errno = EINVAL;
return -1;
@@ -212,6 +220,9 @@
semid++;
if (semid >= SETMAX)
{
+#ifdef DEBUG_IPC
+fprintf(stderr, "darwin: semget failed because all keys were -1 up to SETMAX\n");
+#endif
sem_post(&SemInfo->sem);
errno = ENOSPC;
return -1;
===================================================================
new file:
src/backend/port/darwin/sem.h
instructions:
cp src/backend/port/qnx4/sem.h src/backend/port/darwin/sem.h
then apply patch:
===================================================================
--- ../qnx4/sem.h Wed Apr 12 10:15:30 2000
+++ sem.h Tue Nov 28 22:42:13 2000
@@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
- * $Header: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/qnx4/sem.h,v 1.3 2000/04/12 17:15:30 momjian Exp
$
+ * $Header: $
*
*-------------------------------------------------------------------------
*/
@@ -15,6 +15,9 @@
#ifndef _SYS_SEM_H
#define _SYS_SEM_H
+/* Darwin's sem... shim doesn't quite work yet, best to leave this turned on for now */
+#define DEBUG_IPC
+
#include <sys/ipc.h>
#ifdef __cplusplus
@@ -33,6 +36,10 @@
#define GETZCNT 7 /* get semzcnt */
#define SETVAL 8 /* set semval */
#define SETALL 9 /* set all semval's */
+
+#ifndef ushort_t
+#define ushort_t unsigned int
+#endif
/*
* There is one semaphore structure for each semaphore in the system.
===================================================================
Index: Makefile.in
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/Makefile.in,v
retrieving revision 1.27
diff -u -r1.27 Makefile.in
--- Makefile.in 2000/10/20 21:03:45 1.27
+++ Makefile.in 2000/11/29 06:50:42
@@ -30,6 +30,9 @@
ifeq ($(PORTNAME), beos)
OBJS += beos/SUBSYS.o
endif
+ifeq ($(PORTNAME), darwin)
+OBJS += darwin/SUBSYS.o
+endif
all: SUBSYS.o
SUBSYS.o: $(OBJS)
@@ -45,11 +48,19 @@
beos.dir:
$(MAKE) -C beos all
+darwin/SUBSYS.o: darwin.dir
+
+darwin.dir:
+ $(MAKE) -C darwin all
+
tas.o: tas.s
$(CC) $(CFLAGS) -c $<
distclean clean:
rm -f SUBSYS.o $(OBJS)
+ $(MAKE) -C darwin clean
+ $(MAKE) -C beos clean
+ $(MAKE) -C qnx4 clean
depend dep:
$(CC) -MM $(CFLAGS) *.c >depend
Index: src/backend/port/dynloader/darwin.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/darwin.c,v
retrieving revision 1.3
diff -u -r1.3 darwin.c
--- src/backend/port/dynloader/darwin.c 2000/11/14 21:26:21 1.3
+++ src/backend/port/dynloader/darwin.c 2000/11/29 05:48:51
@@ -10,7 +10,7 @@
#include <mach-o/dyld.h>
#include "dynloader.h"
-void *pg_dlopen(const char *filename)
+void *pg_dlopen(char *filename)
{
NSObjectFileImage image;
@@ -26,7 +26,7 @@
return;
}
-PGFunction pg_dlsym(void *handle, const char *funcname)
+PGFunction pg_dlsym(void *handle, char *funcname)
{
NSSymbol symbol;
char *symname = (char*)malloc(strlen(funcname)+2);
@@ -37,7 +37,7 @@
return (PGFunction) NSAddressOfSymbol(symbol);
}
-const char *pg_dlerror(void)
+char *pg_dlerror(void)
{
return "no error message available";
}
Index: src/backend/port/dynloader/darwin.h
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/darwin.h,v
retrieving revision 1.2
diff -u -r1.2 darwin.h
--- src/backend/port/dynloader/darwin.h 2000/11/09 19:00:50 1.2
+++ src/backend/port/dynloader/darwin.h 2000/11/29 05:48:51
@@ -2,7 +2,7 @@
#include "fmgr.h"
-void *pg_dlopen(const char *filename);
-PGFunction pg_dlsym(void *handle, const char *funcname);
+void* pg_dlopen(char *filename);
+PGFunction pg_dlsym(void *handle, char *funcname);
void pg_dlclose(void *handle);
-const char *pg_dlerror(void);
+char* pg_dlerror(void);
Index: src/backend/storage/buffer/s_lock.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/buffer/s_lock.c,v
retrieving revision 1.26
diff -u -r1.26 s_lock.c
--- src/backend/storage/buffer/s_lock.c 2000/11/28 23:27:55 1.26
+++ src/backend/storage/buffer/s_lock.c 2000/11/29 05:48:51
@@ -119,6 +119,31 @@
#endif /* __m68k__ */
+#if defined(darwin) && defined(__ppc__)
+static void
+tas_dummy()
+{
+ __asm__(" \n\
+ .globl tas \n\
+ .globl _tas \n\
+_tas: \n\
+tas: \n\
+ lwarx r5,0,r3 \n\
+ cmpwi r5,0 \n\
+ bne fail \n\
+ addi r5,r5,1 \n\
+ stwcx. r5,0,r3 \n\
+ beq success \n\
+fail: li r3,1 \n\
+ blr \n\
+success: \n\
+ li r3,0 \n\
+ blr \n\
+ ");
+}
+
+#endif /* __ppc__ && darwin */
+
#if defined(__powerpc__)
/* Note: need a nice gcc constrained asm version so it can be inlined */
static void
Index: src/backend/storage/ipc/ipc.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/ipc/ipc.c,v
retrieving revision 1.54
diff -u -r1.54 ipc.c
--- src/backend/storage/ipc/ipc.c 2000/11/28 23:27:56 1.54
+++ src/backend/storage/ipc/ipc.c 2000/11/29 05:48:51
@@ -52,6 +52,10 @@
#include <sys/ipc.h>
#endif
+#if defined(darwin)
+#include "../backend/port/darwin/sem.h"
+#endif
+
/*
* This flag is set during proc_exit() to change elog()'s behavior,
Index: src/backend/storage/ipc/spin.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/ipc/spin.c,v
retrieving revision 1.26
diff -u -r1.26 spin.c
--- src/backend/storage/ipc/spin.c 2000/11/28 23:27:56 1.26
+++ src/backend/storage/ipc/spin.c 2000/11/29 05:48:51
@@ -21,7 +21,7 @@
#include "postgres.h"
#include <errno.h>
-#ifndef HAS_TEST_AND_SET
+#if !defined(HAS_TEST_AND_SET) && defined(HAVE_SYS_SEM_H)
#include <sys/sem.h>
#endif
Index: src/backend/storage/lmgr/proc.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/lmgr/proc.c,v
retrieving revision 1.84
diff -u -r1.84 proc.c
--- src/backend/storage/lmgr/proc.c 2000/11/28 23:27:56 1.84
+++ src/backend/storage/lmgr/proc.c 2000/11/29 05:48:51
@@ -69,6 +69,11 @@
#include <sys/sem.h>
#endif
+/* Darwin needs a shim for semctl */
+#if defined(darwin)
+#include "../backend/port/darwin/sem.h"
+#endif
+
#include "storage/proc.h"
void HandleDeadLock(SIGNAL_ARGS);
Index: src/include/port/darwin.h
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/include/port/darwin.h,v
retrieving revision 1.1
diff -u -r1.1 darwin.h
--- src/include/port/darwin.h 2000/10/31 19:55:19 1.1
+++ src/include/port/darwin.h 2000/11/29 05:48:51
@@ -1,5 +1,10 @@
+#define darwin
+
+#if defined(__ppc__)
#define HAS_TEST_AND_SET
-#if defined(__powerpc__)
+#endif
+
+#if defined(__ppc__)
typedef unsigned int slock_t;
#else
typedef unsigned char slock_t;
Index: src/template/darwin
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/template/darwin,v
retrieving revision 1.1
diff -r1.1 darwin
1c1,2
< # regular cpp is broken in current development releases
---
> # traditional-cpp means "use gnu cpp" on darwin
> # this should change to -no-cpp-precomp eventually
2a4
>
4c6,7
< CFLAGS=-O0
---
> #CFLAGS=-O2
>
--
bierman@apple.com
"4 out of 5 people with the wrong hardware want to run Mac OS X because..."
http://www.newertech.com/oscompatibility/osxinfo.html
Peter Bierman <bierman@apple.com> writes:
> /* placeholder file for a self-test program I plan to write. pmb-001128 */
I think there is a semaphore-testing program in the QNX port; have you
looked at that?
> +#define darwin
Could we make this symbol __darwin__, or something else a little less
likely to conflict with plain names in the code? (For that matter,
doesn't the compiler predefine some symbol along this line?)
I'd make the latter change myself, except I have no ability to test it.
Please change the patch appropriately and resubmit...
regards, tom lane
Peter Bierman writes:
> Here are patches to CVS top of tree that allow darwin to completely
> build and install. Unfortunately, the sem...() shim does not function
> correctly yet, so it's not stable enough to use.
We've been through this before. Newer Darwin kernels have semaphore
support, which means that you'll at least have to compensate for that. I
believe we agreed that semaphore support for older kernels would be
available as a patch.
> #include "postgres.h"
> #include "storage/ipc.h"
> #include "storage/proc.h"
> -#include <sys/sem.h>
> +//#include <sys/sem.h>
> +#include "sem.h"
No C++ comments.
> -void *pg_dlopen(const char *filename)
> +void *pg_dlopen(char *filename)
Why?
> +#if defined(darwin) && defined(__ppc__)
> +static void
> +tas_dummy()
> +{
> + __asm__(" \n\
> + .globl tas \n\
> + .globl _tas \n\
> +_tas: \n\
> +tas: \n\
> + lwarx r5,0,r3 \n\
> + cmpwi r5,0 \n\
> + bne fail \n\
> + addi r5,r5,1 \n\
> + stwcx. r5,0,r3 \n\
> + beq success \n\
> +fail: li r3,1 \n\
> + blr \n\
> +success: \n\
> + li r3,0 \n\
> + blr \n\
> + ");
> +}
> +
> +#endif /* __ppc__ && darwin */
Here the question was why the existing powerpc code doesn't work. There
are only syntax differences. Any idea?
> +#if defined(darwin)
> +#include "../backend/port/darwin/sem.h"
> +#endif
This doesn't work. There's no guarantee that the source tree is the same
as the build tree.
> 4c6,7
> < CFLAGS=-O0
> ---
> > #CFLAGS=-O2
No commented out things. Either you take -02 or -O0 or you set CFLAGS to
something else, but it has to be set to something.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
At 11:05 AM -0500 11/29/00, Tom Lane wrote:
>Peter Bierman <bierman@apple.com> writes:
>> /* placeholder file for a self-test program I plan to write. pmb-001128 */
>
>I think there is a semaphore-testing program in the QNX port; have you
>looked at that?
Yes, and it allowed the user to manually toggle semaphores, but I want to write something that will do more of a full
regressionsweep and produce a pass or fail result. (Which might be unnecessary if latest darwin kernels actually
implement<sys/sem.h> completely, see below.)
>> +#define darwin
>
>Could we make this symbol __darwin__, or something else a little less
>likely to conflict with plain names in the code? (For that matter,
>doesn't the compiler predefine some symbol along this line?)
Sure.
The only symbols darwin gcc defines are:
#define __MACH__ 1
#define __NATURAL_ALIGNMENT__ 1
#define __APPLE__ 1
#define __GNUC_MINOR__ 95
#define __ppc__ 1
#define __GNUC__ 2
#define __STDC__ 1
#define __DYNAMIC__ 1
#define __APPLE_CC__ 912
#define __BIG_ENDIAN__ 1
So defining one in PG via configure seems best.
At 5:30 PM +0100 11/29/00, Peter Eisentraut wrote:
>Peter Bierman writes:
>
>> Here are patches to CVS top of tree that allow darwin to completely
>> build and install. Unfortunately, the sem...() shim does not function
>> correctly yet, so it's not stable enough to use.
>
>We've been through this before. Newer Darwin kernels have semaphore
>support, which means that you'll at least have to compensate for that. I
>believe we agreed that semaphore support for older kernels would be
>available as a patch.
Can you point me to an archive of that discussion? I'd love for it to be true.
I did the patch on a Mac OS X Public Beta machine, and gave it a quick test on the most recent Mac OS X internal build,
butI didn't try it without the shim on the latest build. I'll try that.
>> +//#include <sys/sem.h>
>
>No C++ comments.
Good to know.
>> -void *pg_dlopen(const char *filename)
>> +void *pg_dlopen(char *filename)
>
>Why?
All of the other ports do not use the const. The code is called from the main sourcebase assuming it's not const. I
chosethe quicker fix of having the darwin code match the rest of the source instead of trying to push the more correct
constdefinition back into the rest of the code.
>> +#if defined(darwin) && defined(__ppc__)
>> +static void
>> +tas_dummy()
>> +{
>> + __asm__(" \n\
>
>Here the question was why the existing powerpc code doesn't work. There
>are only syntax differences. Any idea?
I think it has more to do with Apple's forked gcc than anything else. I don't have a LinuxPPC machine to check if
addingthe rX syntax there would continue to work. Also, the darwin gcc doesn't create the _tas symbol automatically, so
ithas to be declared in the asm routine.
>> +#if defined(darwin)
>> +#include "../backend/port/darwin/sem.h"
>> +#endif
>
>This doesn't work. There's no guarantee that the source tree is the same
>as the build tree.
Fair enough, what would be the right way to include this file then?
>> 4c6,7
>> < CFLAGS=-O0
>> ---
>> > #CFLAGS=-O2
>
>No commented out things. Either you take -02 or -O0 or you set CFLAGS to
>something else, but it has to be set to something.
Ok. I don't see any reason why -O2 shouldn't work, So I'll just pull the line.
Thanks for the feedback! I'm doing the port for personal reasons, but I think it will be a great feature if Mac OS X GM
workswith PG.
-pmb
--
bierman@apple.com
"4 out of 5 people with the wrong hardware want to run Mac OS X because..."
http://www.newertech.com/oscompatibility/osxinfo.html
Peter Bierman <bierman@apple.com> writes:
>> Here the question was why the existing powerpc code doesn't work. There
>> are only syntax differences. Any idea?
> I think it has more to do with Apple's forked gcc than anything
> else. I don't have a LinuxPPC machine to check if adding the rX syntax
> there would continue to work.
I do (have a LinuxPPC machine), so if you'd identify exactly what I
should try, I'll be glad to check this point. Seems like it'd be smart
to minimize the number of PPC variants of this routine.
regards, tom lane
Tom Lane writes:
> > I think it has more to do with Apple's forked gcc than anything
> > else. I don't have a LinuxPPC machine to check if adding the rX syntax
> > there would continue to work.
>
> I do (have a LinuxPPC machine), so if you'd identify exactly what I
> should try, I'll be glad to check this point. Seems like it'd be smart
> to minimize the number of PPC variants of this routine.
Minimize the differences between
+#if defined(darwin) && defined(__ppc__)
+static void
+tas_dummy()
+{
+ __asm__(" \n\
+ .globl tas \n\
+ .globl _tas \n\
+_tas: \n\
+tas: \n\
+ lwarx r5,0,r3 \n\
+ cmpwi r5,0 \n\
+ bne fail \n\
+ addi r5,r5,1 \n\
+ stwcx. r5,0,r3 \n\
+ beq success \n\
+fail: li r3,1 \n\
+ blr \n\
+success: \n\
+ li r3,0 \n\
+ blr \n\
+ ");
+}
+
+#endif /* __ppc__ && darwin */
and
[src/backend/storage/buffer/s_lock.c]
#if defined(__powerpc__)
/* Note: need a nice gcc constrained asm version so it can be inlined */
static void
tas_dummy()
{
__asm__(" \n\
.global tas \n\
tas: \n\
lwarx 5,0,3 \n\
cmpwi 5,0 \n\
bne fail \n\
addi 5,5,1 \n\
stwcx. 5,0,3 \n\
beq success \n\
fail: li 3,1 \n\
blr \n\
success: \n\
li 3,0 \n\
blr \n\
");
}
#endif /* __powerpc__ */
under the constraint that the first version is probably not negotiable.
I'd like to wish that the GNU assembler is a little more forgiving.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> >I think there is a semaphore-testing program in the QNX port; have you
> >looked at that?
> Yes, and it allowed the user to manually toggle semaphores, but I want to write something that will do more of a full
regressionsweep and produce a pass or fail result. (Which might be unnecessary if latest darwin kernels actually
implement<sys/sem.h> completely, see below.)
> >> +#define darwin
> >Could we make this symbol __darwin__, or something else a little less
> >likely to conflict with plain names in the code? (For that matter,
> >doesn't the compiler predefine some symbol along this line?)
> The only symbols darwin gcc defines are:
> #define __MACH__ 1
> #define __NATURAL_ALIGNMENT__ 1
> #define __APPLE__ 1
> #define __GNUC_MINOR__ 95
> #define __ppc__ 1
> #define __GNUC__ 2
> #define __STDC__ 1
> #define __DYNAMIC__ 1
> #define __APPLE_CC__ 912
> #define __BIG_ENDIAN__ 1
> So defining one in PG via configure seems best.
Why not use "__APPLE__"? There probably isn't much hope of running
anything on a Mac with MacOS which isn't also darwin, right? Presumably
the gcc for LinuxPPC does not define __APPLE__??
- Thomas
Thomas Lockhart writes: > Why not use "__APPLE__"? There probably isn't much hope of running > anything on a Mac with MacOS which isn't also darwin, right? What about Rhapsody? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> > Why not use "__APPLE__"? There probably isn't much hope of running
> > anything on a Mac with MacOS which isn't also darwin, right?
> What about Rhapsody?
Yeah, what about it? Are there any production machines which might get
PostgreSQL installed on them? Not so far, otherwise we would have seen a
port, right?
Peter B, comments?
- Thomas
> Peter B, comments?
fwiw (in case I'm coming across as *just* in a bad mood ;), it seems
like the right time to help Apple understand that they should be
building their compiler with predefined symbols so that the machine and
OS type can be identified automatically. In general, one expects that
from the compiler, though I'm sure we have exceptions in our supported
platforms.
- Thomas
At 6:47 PM +0000 11/30/00, Thomas Lockhart wrote: >> > Why not use "__APPLE__"? There probably isn't much hope of running >> > anything on a Mac with MacOS which isn't also darwin, right? >> What about Rhapsody? > >Yeah, what about it? Are there any production machines which might get >PostgreSQL installed on them? Not so far, otherwise we would have seen a >port, right? > >Peter B, comments? Mac OS X exists in two forks at the moment. One of them is Mac OS X server, which is based on mach 2.5, and is a snapshotof the Mac OS X development process from 1999. There are enough customers of this product that Apple has continuedto bring that fork forward onto the latest machines, so that they can smoothly migrate them back onto the top oftree when it ships as a server product. These people are either WebObjects developers who are probably deploying on Solarisor HPUX, or Schools and Workgroups who need a high end AppleShareIP server. Mac OS X top of tree is Mac OS X client, currently available as Mac OS X Public Beta. (Darwin, which is the name for allof the Open Source parts, everything below the window server, is actually slightly more current.) When it's stable enough,the server solution software will be sold on top of this codebase. While there are probably several Mac OS X Server customers that would be interested in PG, I think you can safely concentrateon Mac OS X (client, Public Beta, darwin) with the knowledge that they will eventually come to you. >fwiw (in case I'm coming across as *just* in a bad mood ;), it seems >like the right time to help Apple understand that they should be >building their compiler with predefined symbols so that the machine and >OS type can be identified automatically. In general, one expects that >from the compiler, though I'm sure we have exceptions in our supported >platforms. The list I sent is actually the list that was decided on about a year ago, after trimming a much longer list of stuff thatthe compiler used to export. For that reason, I don't think you'll see it grow. But I don't actually think it should. It's the prupose of configure, not the compiler, to determine the system that's running.Why should the compiler care what varriant of an OS it's running on? It might not even be compiling code for thatOS. Is there some cost of #define __darwin__ in src/template/darwin that I'm not seeing? (not trying to be inflamatoryhere. :-) -pmb -- bierman@apple.com "4 out of 5 people with the wrong hardware want to run Mac OS X because..." http://www.newertech.com/oscompatibility/osxinfo.html
At 5:30 PM +0100 11/29/00, Peter Eisentraut wrote: >Peter Bierman writes: > >> Here are patches to CVS top of tree that allow darwin to completely >> build and install. Unfortunately, the sem...() shim does not function >> correctly yet, so it's not stable enough to use. > >We've been through this before. Newer Darwin kernels have semaphore >support, which means that you'll at least have to compensate for that. I >believe we agreed that semaphore support for older kernels would be >available as a patch. I just talked to the kernel engineer, and semctl & friends will not be in darwin anytime soon. The current Darwin kernel supports the sem_* functions, but not sem_init and sem_destroy (unnamed BSD semaphores). sem_openand sem_close work though. I plan to change the qnx shim code to use named semaphores, and with luck, we'll be offto the races. ;-) I still don't quite know what to do about: >> +#if defined(darwin) >> +#include "../backend/port/darwin/sem.h" >> +#endif > >This doesn't work. There's no guarantee that the source tree is the same >as the build tree. I'm guessing qnx4 doesn't have this problem because they have a <sys/sem.h>, just no implementation. I could put the contents in os.h, though that feels wrong. I could add a CFLAGS+=-Isrc/backend/port/darwin/ either to the affected file's parent directory makefiles, or in template/darwin. Suggestions? -pmb -- bierman@apple.com "4 out of 5 people with the wrong hardware want to run Mac OS X because..." http://www.newertech.com/oscompatibility/osxinfo.html
> >> > Why not use "__APPLE__"? There probably isn't much hope of running
> >> > anything on a Mac with MacOS which isn't also darwin, right?
> >> What about Rhapsody?
> Mac OS X exists in two forks at the moment. One of them is Mac OS X server, which is based on mach 2.5, and is a
snapshotof the Mac OS X development process from 1999. There are enough customers of this product that Apple has
continuedto bring that fork forward onto the latest machines, so that they can smoothly migrate them back onto the top
oftree when it ships as a server product. These people are either WebObjects developers who are probably deploying on
Solarisor HPUX, or Schools and Workgroups who need a high end AppleShareIP server.
> Mac OS X top of tree is Mac OS X client, currently available as Mac OS X Public Beta. (Darwin, which is the name for
allof the Open Source parts, everything below the window server, is actually slightly more current.) When it's stable
enough,the server solution software will be sold on top of this codebase.
> While there are probably several Mac OS X Server customers that would be interested in PG, I think you can safely
concentrateon Mac OS X (client, Public Beta, darwin) with the knowledge that they will eventually come to you.
> >fwiw (in case I'm coming across as *just* in a bad mood ;), it seems
> >like the right time to help Apple understand that they should be
> >building their compiler with predefined symbols so that the machine and
> >OS type can be identified automatically. In general, one expects that
> >from the compiler, though I'm sure we have exceptions in our supported
> >platforms.
> The list I sent is actually the list that was decided on about a year ago, after trimming a much longer list of stuff
thatthe compiler used to export. For that reason, I don't think you'll see it grow.
> But I don't actually think it should. It's the prupose of configure, not the compiler, to determine the system that's
running.Why should the compiler care what varriant of an OS it's running on? It might not even be compiling code for
thatOS. Is there some cost of #define __darwin__ in src/template/darwin that I'm not seeing? (not trying to be
inflamatoryhere. :-)
No, no particular cost, other than in trying to distill the *actual*
properties of our code base down to the fundamental necessities.
In this case, ./configure can test for general properties of the system
as well as simply testing for the signiture used to set up things like
the ports/ files. If there is a testable property, we can write a test
for configure to try. If there is a signiture based on the results of
uname etc then configure can help select files for inclusion. But the
inline code which is #ifdef'd for specific platforms may as well stand
on its own if possible. So, for example, on Linux systems the "#ifdef
__linux__" was provided by the compiler, not by ./configure, though if
we had to we could try to come up with tests for determining that or we
could hardcode the definition into a ports/ file.
In your summary of MacOS-X, you indicated that we could assume a single
supported flavor, since the two existing code forks will eventually
merge. If there are not *other* Mac platforms which define "__APPLE__"
and which could also run PostgreSQL, then that symbol would likely be
the best choice for our inline tests. All imho of course. Peter E. has
been doing extensive work on the configure system recently, and may have
some more or different suggestions.
Regards.
- Thomas
At 5:50 AM +0000 12/1/00, Thomas Lockhart wrote: >In your summary of MacOS-X, you indicated that we could assume a single >supported flavor, since the two existing code forks will eventually >merge. If there are not *other* Mac platforms which define "__APPLE__" >and which could also run PostgreSQL, then that symbol would likely be >the best choice for our inline tests. Well, it's hard for me to say definitively. But I don't think there are other POSIX-like OS implementations that define __APPLE__ On a different note, the same kernel engineer wrote me back a few minutes ago to tell me that named semaphores actually startedworking with *today's* kernel. So it looks like running it on Mac OS X Public Beta will tickle a kernel bug in thatrelease. Any opinions on the best way to check for this and warn the user? I'm thinking of creating a darwin_startup() called from backend/main/main.c that would check the system version and abortthe startup if the system version is too old. I don't want to make it a compile time check, because I'm sure there willbe people grabbing binary distributions after X-GM is available and trying them on X-PB. -pmb -- bierman@apple.com "4 out of 5 people with the wrong hardware want to run Mac OS X because..." http://www.newertech.com/oscompatibility/osxinfo.html
> Well, it's hard for me to say definitively. But I don't think there are other POSIX-like OS implementations that
define__APPLE__
OK, that sounds like a winner for now...
> On a different note, the same kernel engineer wrote me back a few minutes ago to tell me that named semaphores
actuallystarted working with *today's* kernel. So it looks like running it on Mac OS X Public Beta will tickle a kernel
bugin that release.
> Any opinions on the best way to check for this and warn the user?
Hmm. MacOS X Public Beta. PostgreSQL-7.1beta. Lots of betas, and no
releases (yet). So what is to warn about? You will possibly be testing
on upcoming snapshots and betas and full releases, so we will have some
feedback on whether things look good for PostgreSQL-7.1 and MacOS-X
released versions. And we'd be happy to have a MacOS-X FAQ in our
sources and binary distros, so at that point the users can either help
with development or read the FAQ and stay away.
I'm sure some of your constituancy is not used to this style of "user
beware" system, so you'll want to help them as much as possible, but...
> I'm thinking of creating a darwin_startup() called from backend/main/main.c that would check the system version and
abortthe startup if the system version is too old. I don't want to make it a compile time check, because I'm sure there
willbe people grabbing binary distributions after X-GM is available and trying them on X-PB.
... this seems to be overkill. Hardcoding some defensive checks in the
server backend to guard against improper installations of this nature
seems to be the wrong direction to take. For Linux, one could put these
kinds of checks in the RPM installation script, and RPM will decline to
proceed if the checks fail. What sort of installation environment does
MacOS-X have? What will binary distros look like? If there are, say,
installation scripts then checks could be put there. Or if the distro
will have a startup script then the checks could be put there. But
compiling that into the backend? We haven't had to do that for other
platforms, and it would be nice to avoid a Mac-only appendage in the
compiled source code.
Again, all imho and not meant to be annoying or unhelpful...
- Thomas
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> I'm thinking of creating a darwin_startup() called from
>> backend/main/main.c that would check the system version and abort the
>> startup if the system version is too old.
> ... this seems to be overkill.
I agree with Thomas here: platform-specific warts with a short life
expectancy are a bad idea. We have more than enough warts already.
We don't need to hard-wire a check that tells people running on a
beta OS release that that beta has bugs.
regards, tom lane
At 2:01 AM -0500 12/1/00, Tom Lane wrote: >Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >>> I'm thinking of creating a darwin_startup() called from >>> backend/main/main.c that would check the system version and abort the >>> startup if the system version is too old. > >> ... this seems to be overkill. > >I agree with Thomas here: platform-specific warts with a short life >expectancy are a bad idea. We have more than enough warts already. >We don't need to hard-wire a check that tells people running on a >beta OS release that that beta has bugs. I was going to say I disagree, but then I remembered that the beta has a (well documented) timebomb, so it will indeed bea moot issue eventually. >>What sort of installation environment does >>MacOS-X have? What will binary distros look like? Funny you should ask, since my real job is to work on the Installer. PG is not the kind of thing we'd make a GUI install package for, at least not yet. The PG user is going to need to use thecommand line to interact with it, so they might as well use it to install it. As such, binary dists would probably justbe a tarball. In other news, I just (litterally a minute ago) fixed the last issues with my port (hurray!), and the regression test passesevery test except geometry, where the diffs differ in the 15th decimal digit for the last coordinate pair. Roundingerror somewhere? Do the regression tests adequately stress semaphores? Are semephores used interprocess? Do the regression tests cause thissort of use to be tested? The only thing I'm worried about is that the regression tests simulate an artifically sequential load. And any suggestions on how to include my sem.h? I can send in the revised patch as soon as that's resolved. Thanks! -pmb -- bierman@apple.com "4 out of 5 people with the wrong hardware want to run Mac OS X because..." http://www.newertech.com/oscompatibility/osxinfo.html
>and the regression test passes every test except geometry, where the diffs >differ in the 15th decimal digit for the last coordinate pair. Rounding >error somewhere? > >Do the regression tests adequately stress semaphores? Are semephores used >interprocess? Do the regression tests cause this sort of use to be tested? > >The only thing I'm worried about is that the regression tests simulate an >artifically sequential load. And I'm dumb, and should RTFM before asking these questions. (Answers to above: no, probably, yes, & yes.) Would you believe I've yet to write a single line of SQL? Gotta start somewhere. -pmb -- bierman@apple.com "4 out of 5 people with the wrong hardware want to run Mac OS X because..." http://www.newertech.com/oscompatibility/osxinfo.html
Peter Bierman <bierman@apple.com> writes:
> In other news, I just (litterally a minute ago) fixed the last issues
> with my port (hurray!), and the regression test passes every test
> except geometry, where the diffs differ in the 15th decimal digit for
> the last coordinate pair. Rounding error somewhere?
Do the results match either of the existing expected-files for powerpc
systems?
> Do the regression tests adequately stress semaphores? Are semephores
> used interprocess? Do the regression tests cause this sort of use to
> be tested?
The parallel format ("make check") provides at least some confidence.
The regress tests don't really exercise IPC very thoroughly though :-(
regards, tom lane
Peter Bierman <bierman@apple.com> writes:
> But I don't actually think it should. It's the prupose of configure,
> not the compiler, to determine the system that's running. Why should
> the compiler care what varriant of an OS it's running on? It might not
> even be compiling code for that OS.
Yeah, but header files care, and predefined symbols are the only way
that the C compiler can pass what it knows about the target environment
(which it *must* know about, in some fashion) to header files.
To take one example, what if a header file needs to know whether it's
being compiled under Rhapsody or Darwin?
> Is there some cost of #define __darwin__ in src/template/darwin that
> I'm not seeing? (not trying to be inflamatory here. :-)
I was just reminded of another reason why we like compiler-provided
symbols of this kind better than hacking one up in the port's header
file: you don't have to be very careful about whether such a symbol
is defined yet or not. For example, our config.h has
/*
* Define this if your operating system supports AF_UNIX family sockets.
*/
#if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
# define HAVE_UNIX_SOCKETS 1
#endif
which works fine, but only because those are all compiler-predefined
symbols --- the port-specific os.h file hasn't been included yet.
("Rearrange the code" isn't a very good retort, because that just
introduces other ordering problems.)
You might want to think about having the template/darwin file add
-D__darwin__ to CPPFLAGS, instead of putting a #define in port/darwin.h.
And have another go at convincing Apple that they're wrong not to have
their compiler provide such a symbol automatically.
regards, tom lane
At 12:30 PM -0500 12/2/00, Tom Lane wrote: >You might want to think about having the template/darwin file add >-D__darwin__ to CPPFLAGS, instead of putting a #define in port/darwin.h. This is what I ended up with. My plans for the #include "../backend/port/darwin/sem.h" are to change the Makefile.in in the directories that have sourcethat needs to #include my "sem.h" to add a -I../backend/port/darwin/ That way the change happens from inside the sourcetree, no worries about the header search tree moving. Any objections? Finally, after one of our kernel engineers gave me the skinny on semaphore support, I almost have it working correctly. I'vemade a LOT of changes to the qnx shim to use named POSIX semaphores. The general method sort of the same, and I've alsoadded a ton of conditional debugging output. Two questions: Q1) should I submit with the debugging stuff in the code (conditionalized off of course). It's useful if someone wants tosee how it works, but it makes the code a bit harder to read. Q2) As I'm 95% done making it work as a shim, I notice that the Sem stuff is shimmed in Postgres also, and I wonder if there'dbe objections to me conditionalizing it there. It would be a LOT easier to change the InternalIpc...() to use POSIXnamed semaphores vs my current route of implementing SysV semaphores as a shim on top of POSIX ones. I could conditionalize the code on HAS_POSIX_SEMAPHORES or DARWIN_HAS_POSIX_SEMAPHORES, and only set it on darwin for now.Other platforms could try it and migrate over if it works. Part of me thinks this would be better for PG as a whole,moving towards POSIX and all that... Comments? Also, one of the things that got me into a mess is that the postmaster allocates some sem arrays via semget(), and then letsits children use the semids that were returned in the parent process. I can't find any docs that say this is legal, thoughobviously it must work. The Vahalia book on Unix Internals describes implementation that explains *why* it works, butsort off alludes that it shouldn't. Also, should I be asking these questions on pg-hackers instead of here? -pmb -- "Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make." http://joel.editthispage.com/stories/storyReader$51
Peter Bierman <bierman@apple.com> writes:
> Q2) As I'm 95% done making it work as a shim, I notice that the Sem
> stuff is shimmed in Postgres also, and I wonder if there'd be
> objections to me conditionalizing it there. It would be a LOT easier
> to change the InternalIpc...() to use POSIX named semaphores vs my
> current route of implementing SysV semaphores as a shim on top of
> POSIX ones.
POSIX IPC isn't compatible with SysV IPC? News to me. Chapter and
verse, please?
> Also, one of the things that got me into a mess is that the postmaster
> allocates some sem arrays via semget(), and then lets its children use
> the semids that were returned in the parent process. I can't find any
> docs that say this is legal, though obviously it must work. The
> Vahalia book on Unix Internals describes implementation that explains
> *why* it works, but sort off alludes that it shouldn't.
Nonsense. HPUX's semget() man page says:
... This call creates a new identifier,
subject to available resources. The identifier is never returned
by another call to semget() until it has been released by a call
to semctl(). The identifier should be used among the calling
process and its descendents; however, it is not a requirement.
The resource can be accessed by any process having the proper
permissions.
I'd say that makes it perfectly clear that semaphore identifiers are
system-wide, and *certainly* makes it clear that a semid may be passed
down to child processes.
> Also, should I be asking these questions on pg-hackers instead of here?
Probably. I don't think pgpatches is very widely read.
regards, tom lane
At 1:31 AM -0500 12/5/00, Tom Lane wrote: >Peter Bierman <bierman@apple.com> writes: >> Q2) As I'm 95% done making it work as a shim, I notice that the Sem >> stuff is shimmed in Postgres also, and I wonder if there'd be >> objections to me conditionalizing it there. It would be a LOT easier >> to change the InternalIpc...() to use POSIX named semaphores vs my >> current route of implementing SysV semaphores as a shim on top of >> POSIX ones. > >POSIX IPC isn't compatible with SysV IPC? News to me. Chapter and >verse, please? Didn't say that. They're just two different APIs for doing semaphores. Darwin has the POSIX API, and not the SysV API, andPG uses the SysV API. I'm implementing the SysV API for PG as a shim on top of the POSIX API. Since PG uses it's own shim to go from internal functions to the SysV API, I'm asking if there'd be objection to me implementingthe conditional code in src/backend/storage/ipc.c, having PG's shim use POSIX API directly. PG doesn't use anyof the fancy features of the SysV API, just create, set, release, and inspect. > >> Also, one of the things that got me into a mess is that the postmaster >> allocates some sem arrays via semget(), and then lets its children use >> the semids that were returned in the parent process. I can't find any >> docs that say this is legal, though obviously it must work. The >> Vahalia book on Unix Internals describes implementation that explains >> *why* it works, but sort off alludes that it shouldn't. > >Nonsense. HPUX's semget() man page says: > > ... This call creates a new identifier, > subject to available resources. The identifier is never returned > by another call to semget() until it has been released by a call > to semctl(). The identifier should be used among the calling > process and its descendents; however, it is not a requirement. > The resource can be accessed by any process having the proper > permissions. > >I'd say that makes it perfectly clear that semaphore identifiers are >system-wide, and *certainly* makes it clear that a semid may be passed >down to child processes. Yup. Like I said, I couldn't find anything that said it was legal. That's why I asked, and you kindly provided the proofthat it was. I figured it must be, since it's obviously working for PG on a dozen or more platforms, but it seemed odd. In any case, my problem is that darwin doesn't currently have any similar construct. I can't create a semaphore that canbe transparently passed to a child while in use. I can create a named semaphore that children can open when they wantit, which will work the same way. But to preserve PG's semid semantics, I have to do a lot of goofy hacks in my shimto keep track of semids across processes. It would be easier to just move up a level in the stack and change PG's shimto use POSIX API. After all, someone had the foresight of giving PG a shim for Semaphores, might as well use it! -pmb -- "Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make." http://joel.editthispage.com/stories/storyReader$51
Peter Bierman <bierman@apple.com> writes:
>> POSIX IPC isn't compatible with SysV IPC? News to me. Chapter and
>> verse, please?
> Didn't say that. They're just two different APIs for doing semaphores.
I'm still startled. Why would the POSIX guys have invented their own
API, rather than standardizing on the well-entrenched SysV IPC calls?
They did not have a charter to invent new stuff.
> Since PG uses it's own shim to go from internal functions to the SysV
> API, I'm asking if there'd be objection to me implementing the
> conditional code in src/backend/storage/ipc.c, having PG's shim use
> POSIX API directly.
No objection here, but I wonder whether you'll find that it helps.
The ipc.c code is so thin that it doesn't really hide any SysV
semantics. In particular, it will not help you to hack ipc.c if your
problem is that child processes don't inherit access to semaphores
created by their parent. (But that would be so impossibly brain-dead
that I do not believe it...)
regards, tom lane
Tom Lane writes:
> > Is there some cost of #define __darwin__ in src/template/darwin that
> > I'm not seeing? (not trying to be inflamatory here. :-)
I think that all in all it's okay to #define __darwin__ in
include/port/darwin.h until proven not so, given that there are much worse
hacks in there (e.g. unixware). Putting -D options on the command line is
uglier than sin IMHO.
> I was just reminded of another reason why we like compiler-provided
> symbols of this kind better than hacking one up in the port's header
> file: you don't have to be very careful about whether such a symbol
> is defined yet or not. For example, our config.h has
>
> /*
> * Define this if your operating system supports AF_UNIX family sockets.
> */
> #if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
> # define HAVE_UNIX_SOCKETS 1
> #endif
>
> which works fine, but only because those are all compiler-predefined
> symbols --- the port-specific os.h file hasn't been included yet.
> ("Rearrange the code" isn't a very good retort, because that just
> introduces other ordering problems.)
A code reordering of the config.h, c.h, postgres.h chain is definitely
necessary IMO, especially since I'd like to start generating config.h.in
automatically with autoheader when Autoconf 2.50 is out. Then we could
reserve config.h for autoconf-determined "facts", put the "evaluation" of
config.h as necessitated by the PostgreSQL code into c.h, and maybe make
postgres.h backend-specific stuff only. The above statement should really
go into c.h then.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Date: Tue, 05 Dec 2000 10:58:15 -0500 From: Tom Lane <tgl@sss.pgh.pa.us> Peter Bierman <bierman@apple.com> writes: >> POSIX IPC isn't compatible with SysV IPC? News to me. Chapter and >> verse, please? > Didn't say that. They're just two different APIs for doing semaphores. I'm still startled. Why would the POSIX guys have invented their own API, rather than standardizing on the well-entrenched SysV IPC calls? They did not have a charter to invent new stuff. The POSIX semaphore interface comes from the pthreads work. In my opinion, the System V IPC calls are badly designed. I haven't done much work with POSIX semaphores, but they are simpler and more efficient to implement. > Since PG uses it's own shim to go from internal functions to the SysV > API, I'm asking if there'd be objection to me implementing the > conditional code in src/backend/storage/ipc.c, having PG's shim use > POSIX API directly. No objection here, but I wonder whether you'll find that it helps. The ipc.c code is so thin that it doesn't really hide any SysV semantics. In particular, it will not help you to hack ipc.c if your problem is that child processes don't inherit access to semaphores created by their parent. (But that would be so impossibly brain-dead that I do not believe it...) Believe it. Having semaphores be shared between processes is optional when using POSIX semaphores. GNU/Linux, at least with glibc 2.1, does not implement sharing semaphores between processes. However, on systems which do fully implement POSIX semaphores, it should be easy for Postgres to use them. They should be created in the shared memory segment. Ian
Ian Lance Taylor <ian@airs.com> writes:
> The POSIX semaphore interface comes from the pthreads work. In my
> opinion, the System V IPC calls are badly designed.
Badly implemented, I'll grant you --- the resource limits in a typical
configuration are ridiculously low. I'm not sure the API as such is
particularly good or bad.
> However, on systems which do fully implement POSIX semaphores, it
> should be easy for Postgres to use them. They should be created in
> the shared memory segment.
Huh? Are POSIX semaphores objects in user memory space, instead of
in the kernel? I'm getting more and more confused. Where can I find
a description of the POSIX version of semaphores?
BTW, should I expect that POSIX also ignored the SysV IPC spec for
shared memory?
regards, tom lane
Date: Tue, 05 Dec 2000 12:28:59 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
Ian Lance Taylor <ian@airs.com> writes:
> The POSIX semaphore interface comes from the pthreads work. In my
> opinion, the System V IPC calls are badly designed.
Badly implemented, I'll grant you --- the resource limits in a typical
configuration are ridiculously low. I'm not sure the API as such is
particularly good or bad.
A matter of taste, I suppose.
> However, on systems which do fully implement POSIX semaphores, it
> should be easy for Postgres to use them. They should be created in
> the shared memory segment.
Huh? Are POSIX semaphores objects in user memory space, instead of
in the kernel? I'm getting more and more confused. Where can I find
a description of the POSIX version of semaphores?
POSIX semaphores can in principle live in either user space or kernel
space. They are mainly designed for user space, though.
If you have access to a GNU/Linux system, you can do `man sem_init'.
Or, I just did a quick web search, and found this:
http://helix.nih.gov/cgi-bin/man.cgi?section=3&topic=sem_init
BTW, should I expect that POSIX also ignored the SysV IPC spec for
shared memory?
Yes. POSIX.1 standardizes mmap instead.
Ian
Ian Lance Taylor <ian@airs.com> writes: > Where can I find > a description of the POSIX version of semaphores? > POSIX semaphores can in principle live in either user space or kernel > space. They are mainly designed for user space, though. > If you have access to a GNU/Linux system, you can do `man sem_init'. > Or, I just did a quick web search, and found this: > http://helix.nih.gov/cgi-bin/man.cgi?section=3&topic=sem_init Hm. It's clearly possible to base Postgres's semaphore stuff on unnamed Posix semaphores living in the shared memory area (which eliminates the issue of inheritance by child processes). You'd need to revise the API presented by ipc.c so that it doesn't depend on semaphore IDs and keys. I'm inclined to envision a type "pg_semaphore" that's either "sem_t" in the POSIX case or struct { int sem_id, sem_num; } in the SysV case, and then all the ipc.c routines take a pg_semaphore *. There's some code to allocate semaphores to backends in proc.c that would need to be rewritten, but the impact ought to be pretty localized. How efficient are POSIX semaphores, anyway? I wonder if we couldn't also replace spinlocks with them... > BTW, should I expect that POSIX also ignored the SysV IPC spec for > shared memory? > Yes. POSIX.1 standardizes mmap instead. Another TODO item I suppose :-( regards, tom lane
Tom Lane writes: > How efficient are POSIX semaphores, anyway? I wonder if we couldn't > also replace spinlocks with them... There are POSIX spinlocks as well, though I haven't actually seen one... > > BTW, should I expect that POSIX also ignored the SysV IPC spec for > > shared memory? > > > Yes. POSIX.1 standardizes mmap instead. > > Another TODO item I suppose :-( It's already there. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
At 2:46 PM -0500 12/5/00, Tom Lane wrote: >Hm. It's clearly possible to base Postgres's semaphore stuff on unnamed >Posix semaphores living in the shared memory area (which eliminates the >issue of inheritance by child processes). You'd need to revise the API >presented by ipc.c so that it doesn't depend on semaphore IDs and keys. Heh. True, but unfortunately Apple hasn't implemented _unnamed_ POSIX semaphores yet. (Please don't shoot the messenger,I'll kill myself.) But my patch to ipc.c to use named semaphores is actually pretty compact. It conditionalizes the function bodies of IpcSemaphoreLockand related, and it changes the typedef of a IpcSemaphoreId from a int to a long, so I just pass the keyused to create the semaphore back as the semid. -pmb -- "Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make." http://joel.editthispage.com/stories/storyReader$51