On Wed, Apr 4, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: > Aaron Stone wrote: >> On Wed, Apr 4, 2007, [EMAIL PROTECTED] said: >> >>> A NOTE has been added to this issue. >>> ====================================================================== >>> http://www.dbmail.org/mantis/view.php?id=561 >> >>> Error Error setting lock. Trying again. >>> Error Error setting lock. Trying again. >> >>> You're actually seeing a problem in pool.c, set_lock. >> >> I wonder if we could switch to locking through the shared memory region >> itself rather than relying on the operating system to provide us with a >> lock file and correct operation of fnctl. Maybe just have the first byte >> of the shared memory contain a few lock bits and operate on those. > > The reason for using fcntl file locks was because it's well tested and > understood. Creating a reliable locking system is not trivial in my > experience.
Semaphores ok? http://www.ecst.csuchico.edu/~beej/guide/ipc/semaphores.html >> I don't think it's all that critical, though. This message should probably >> be a MESSAGE level rather than ERROR, and we should add a counter so that >> if it takes more than, say, 5 tries, we throw an error. > > Well, there's probably no need for such a loop at all. Lets make EDEADLK > and EACCESS be real errors that return, but for EAGAIN issue a warning > and recurse. > > I-am-not-a-kernel-hacker though, so checking the posix docs might be useful. EDEADLK appears to mean that the process is already holding the lock. As long as we don't call any of the scoreboard functions from within signal handlers, I don't think this can happen. Separating out the three conditions with different log messages would allow us to see the distribution of error conditions. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
