Antw: Re: Native Win32/OS2/BeOS/NetWare ports

Hi Igor,

Thanks for your information.

I was aware of the "signal" problems and i've done it with thread based
signals
This part is functional on my platform but it isn't fully cooked.
Another problem
is to make this part portable.

Your assumption to replace SysV semaphores with POSIX semaphores is
correct.
My first guess was to use mutexes instead of semaphores at all because
the
way semaphores are used in Postgres is more something like a "mutex",
but only semaphores worked for me at this time because the underlying
C Library had some problems with mutexes and spinlocks. (I'm also
working on a new C Library for a future OS).

Actually I don't have my code downloadable somewhere because the code
doesn't look very nice in some parts. There is also temporary debug
code
in it right now. The best I think is to send it to you via email. If
this is OK
please give me a short notice or send an email to me and I'll send you
a
copy.

Ulrich

>>> "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com> 11.06.2002 20:14:58
>>>
> 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

---------------------------(end of
broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html
----------------------------------
This e-mail is virus scanned
Diese e-mail ist virusgeprueft