Hi all, sorry in advance if this is a dumb question. The apr documentation for apr_file_lock states "Locks are established on a per-thread/process basis; a second lock by the same thread will not block." but this is not the behavior I am seeing. As apr_file_lock on unix uses fcntl by default, a second lock by another thread of the same process will not lock either.
I was using apr_file_lock as I need all my httpd threads/process to be synchronized on an named ressource, and chose to create a lockfile who's filename matches my named ressource. This does not work as with a multi-threaded mpm the threads of the same process that created the lockfile will not block on the call to apr_file_lock call. >From my readings, it seems that file locking is a hazardous task to get right, so what are my options to attain my goal: - use my own implementation mimicking apr_file_lock, but that unconditionnaly uses flock() instead of fcntl() ? I suspect that this would not be a safe solution as some platforms fall back to fcntl for flock. - I tried using a posix semaphore which worked quite well, except in the cases where either the process crashed or was terminated by httpd because of a Timeout, and in that case the semaphore is never released until a server reboot or manually messing in /dev/shm. If I attach a cleanup call to the request pool, will it be called in the case where the process is terminated after the Timeout delay ? thank you for reading up to here, Thomas
