Hi Petr, -=| Petr Salinger, Tue, Jan 19, 2010 at 12:55:27PM +0100 |=- > The current GNU/kFreeBSD does not support process-shared pthread > mutexes. It also does not support process-shared semaphores. > > Is the inter-process sharing really necessary ? > The calls inside are in a form of sem_init(sem, 0, 0), i.e. only > thread-shared.
Thank you for your time looking into this. Just to give you a raugh idea, Firebird comes in three flavours. "superserver" - a multi-threaded daemon handling many connections, but being able to use only one CPU (long story). this one seems to need only thread synchronization. "classicserver" - a new process is started (via inetd) for each connection and these processes shall be able to communicate. I am not sure about the mechanisms of this communication, but it may well be shared memory and signals. Or semaphores. "superclassic" - a mix of the above, but closer to "classic" Firebird IPC is black magic. I am not sure if process-shared semaphores are really needed. "superserver" seems to not need them at all (at least on theory). And still it fails to build. The place it fails is interesting, though. The checkMutex function (src/jrd/trace/TraceConfigStorage.cpp line 147)[1] is what bails out. It is called from various places, but the one matching the error message is at line 182, in function initShMem. The argument that is the error code is the result of calling ISC_mutex_init, which is defined in src/jrd/isc_sync.cpp, in two flavours depending on the USE_SYS5SEMAPHORE define (another flavour is for windows). [1] http://git.debian.org/?p=pkg-firebird/2.5.git;a=tree (line numbers may differ because some patches are applied) I guessed that USE_SYS5SEMAPHORE is not defined, as it is currently linked to the DARWIN define. This is why I thought that defining USE_SYS5SEMAPHORE should help. Are you suggesting that it won't? BTW, the SYSV variant (line 2749) would only return 0 or FB_FAILURE (1) and not 78 (which is visible in the build log), so there must be the other, non-SYSV implementation that fails (line 2886). That one seems to use posix threads functions all over the place and I have no idea which exactly may be failing. I will ask the porter box admins to install the build-dependencies (+gdb) so that I can try tracing the failure and see which exact function fails. Other clues are welcome, of course.
signature.asc
Description: Digital signature