Обсуждение: Native Win32/OS2/BeOS/NetWare ports

Поиск
Список
Период
Сортировка

Native Win32/OS2/BeOS/NetWare ports

От
"Ulrich Neumann"
Дата:
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


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


--ELM1023904350-8181-0_--


Re: Native Win32/OS2/BeOS/NetWare ports

От
"Igor Kovalenko"
Дата:
> 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