Re: Native Win32/OS2/BeOS/NetWare ports - Mailing list pgsql-hackers

From Igor Kovalenko
Subject Re: Native Win32/OS2/BeOS/NetWare ports
Date
Msg-id 00c901c21173$e5f95870$22c30191@comm.mot.com
Whole thread Raw
In response to Native Win32/OS2/BeOS/NetWare ports  ("Ulrich Neumann" <U_Neumann@gne.de>)
List pgsql-hackers
> 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




pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: New string functions; initdb required
Next
From: Stephan Szabo
Date:
Subject: Re: Referential integrity problem postgresql 7.2 ?