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" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster