Native Win32/OS2/BeOS/NetWare ports
Hello together
i've seen a lot of discussion about a native win32/OS2/BEOS port of
PostgreSQL.
During the last months i've ported PostgreSQL over to Novell NetWare
and i've
changed the code that I use pthreads instead of fork() now.
I had a lot of work with the variables and cleanup but mayor parts are
done.
I would appreciate if we could combine this work.
My plan was to finish this port, discuss the port with other people and
offer all the work
to the PostgreSQL source tree, but now i'm jumping in here because of
all the discussions.
What i've done in detail:
- i've defined #USE_PTHREADS in pg_config.h to differentiate between
the forked and the
threaded backend.
- I've added several parts in postmaster.c so all functions are based
on pthreads now.
- I've changed the signal handling because signals are process based
- I've changed code in ipc.c to have a clean shutdown of threads
- I've written some functions to switch the global variables. The
globals are controled with
POSIX semaphores.
- I've written a new implementation of shared memory and semaphores-
With pthreads I don't
need real shared memory any more and i'm using POSIX semaphores now
- Several minor changes.
There is still some more work to do like fixing memory leaks or
handling bad situations, but in general it's
functional on NetWare.
BTW: Is it possible to add some lines on the PostgreSQL webpage that
there is a first beta of
PostgreSQL for NetWare available and to offer a binary download for the
NetWare version?
Ulrich Neumann
----------------------------------
This e-mail is virus scanned
Diese e-mail ist virusgeprueft
Hello together
i've seen a lot of discussion about a native win32/OS2/BEOS port of
PostgreSQL.During the last months i've ported PostgreSQL over to Novell NetWare
and i've
changed the code that I use pthreads instead of fork() now.I had a lot of work with the variables and cleanup but mayor parts are
done.I would appreciate if we could combine this work.
Very nice... I have patches for QNX6 which also involved redoing shared
memory and sempahores stuff. It would make very good sense to intergate,
especially since you managed to do something very close to what I wanted :)
My plan was to finish this port, discuss the port with other people and
offer all the work
to the PostgreSQL source tree, but now i'm jumping in here because of
all the discussions.What i've done in detail:
- i've defined #USE_PTHREADS in pg_config.h to differentiate between
the forked and the
threaded backend.
- I've added several parts in postmaster.c so all functions are based
on pthreads now.
- I've changed the signal handling because signals are process based
Careful here. On certain systems (on many, I suspect) POSIX semantics for
signals is NOT default. Enforcing POSIX semantics requires certain compile
time switches which will also change behavior of various functions.
- I've changed code in ipc.c to have a clean shutdown of threads
- I've written some functions to switch the global variables. The
globals are controled with
POSIX semaphores.
- I've written a new implementation of shared memory and semaphores-
With pthreads I don't
need real shared memory any more and i'm using POSIX semaphores now
POSIX semaphores for what? I assume by the conext that you're talking about
replacing SysV semaphores which are used to control access to shared memory.
If that is the case, POSIX semaphores are not the best choice really. POSIX
mutexes would be okay, but on SMP systems spinlocks (hardware TAS based
macros or POSIX spinlocks) would probably be better anyway. Note that on
most platforms spinlocks are used for that and SysV semaphores were just a
'last resort' which had unacceptable performance and so I guess it was not
used at all.
Do you have your patch somewhere online?
-- igor