In a private message Christopher Key gave the correct hint to solve the problem: the program was missing the appropriate initialization every APR based application must do by calling apr_app_initialize (and apr_terminate upon application exit).
As an apology for my hapless inability to understand I would like to point out that at least another APR module I personally tested (shared memory), works pretty well on Linux without any apr_initialize() call at all. -- Massimo On Wed, 09 Mar 2011 10:54:48 +0100, Massimo Manghi wrote:
I'm perhaps not very polite asking on this list without waiting the usual lurking time, but I've been googling this problem for a while yesterday and I did not find out anything about it. Still the problem is very clear: I wrote a sort of 'hello world' program where a global mutex is created to synchronize access to a resource shared between a parent and a child process created with a Unix 'fork' call. The child *should* gain the lock first, as the parent is given a 2 seconds wait before attempting to lock the mutex. Then it should release the lock giving way to the parent. That's all. Simply the calls to apr_global_mutex_[lock|trylock|unlock] wait forever and never return. I also thought the apr_global_mutex_create returned an implicitly locked mutex and tried to unlock it. Also this call would block forever. Where did I get it wrong? I asked also other people who are using global mutexes in their projects and they observed the same problem when they run my program and could not give an explanation. The program is so simple that I dare attach it here. It is a way to become familiar with tools that I hope will be used to design and implement a new software component to be developed for Apache Rivet, if this can work as an excuse for my intrusiveness. thanks for any help. -- Massimo Manghi
