>>>>> "eno" == eno <[EMAIL PROTECTED]> writes:
eno> Marco Bambini wrote: >> After the 2.8.10 release ... "This version fixes a critical locking >> bug in Unix. It turns out that any call to close() clears all locks >> on file that was closed (who knew?) which then left the database >> vulnerable to corruption from other processes. That bug has been >> cleared by embargoing all close() calls until all locks of been >> released." I have made some investigation... From "Advanced >> Programming in the UNIX Environment" by R. Stevens: eno> thank you for this clarification. But what does R. Stevens write eno> about how to circumvent this strange behaviour? I sent some info to the list earlier this week on this subject, but I believe I sent it from the wrong address. Anyway, I also looked through Stevens this past weekend and I didn't find any suggestions in particular to work around this. Although, he does have an explanation of why when close() is called that the kernel can't tell if the file descriptor being closed has the associated lock(s) or not. I can look it up again tonight and post the relevant information if people are interested. After looking at the locking and the IPC sections of Stevens, I came up with the following idea. Please make any suggestions, corrections etc. >From my understanding this problem will only appear within the same process id. An advisory lock will work between different process and this includes across a fork(), but maybe not across an exec(). So the corruption can only occur when 2 or more file descriptors are opened within the same process id. This would include multithreaded applications in which all the threads have the same PID, and it also is evident in Linux where threads have different PID's. As a possible solution, use a shared memory semaphore locking scheme to replace the advisory record locking system currently being used. I thought the generation of the shared memory key_t might be a problem but using ftok() with the database filename should work just fine. I can see an advantage with this system in that you wouldn't need to use a combination of advisory locking (for between processes) with mutexes (for within the same process) to ensure safety. One system, semaphores could be used. Additionally, according to data in Stevens, using a semaphore is faster than using an advisory lock. But I don't think this includes the allocation and destruction of the shared memory used by the semaphores. And locking is probably not a performance bottleneck within SQLite. Of course the huge disadvantage to this system is that if the process with sqlite is killed for some reason, there could be spare shared memory lying around. That may be an unacceptable risk. I haven't completely thought through all the ramifications of using semaphores, but I figured it wouldn't hurt to share my thoughts up to this point. Maybe it will help. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
