Brad House <[EMAIL PROTECTED]> wrote: > >> they have put traces and identified that for 1000 lock calls > >> there are only 950 unlock calls, which is a shortage of 50 unlock > >> calls. > > The os_unix.c backend to SQLite makes no attempt to match lock/unlock > > calls, because posix does not requires such. If you are running > > on an operating system that does require matching lock/unlock calls, > > you will probably need to modify the os_unix.c layer in order for it > > to work properly on your system. > > I'm not sure what you're getting at here. Are you saying that it's > possible that some mutexes will _never_ be unlocked? In what circumstance > does that occur? Is there a case where a mutex could be destroyed while > a lock is held? I know my linux 'man pthread_mutex_destroy' says > "Attempting to destroy a locked mutex results in undefined behavior". > > Under what circumstances does this "lock leakage" occur exactly?
There are no lock leaks. But on the other hand, there is not a one-to-one mapping of lock to unlock calls. unlock is called more often than lock and there are often attempts to unlock files that have never been locked, irrc. This is harmless on windows and unix. -- D. Richard Hipp <[EMAIL PROTECTED]> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
