On Fri, 2009-10-30 at 12:01 +0100, Stefan Ruppert wrote: > I don't know the concept behind APR_FOPEN_XTHREAD, but after a quick > look into the trunk source code this seems to only protect the > buffered io but not the file structure itself. > > From my point of view if an application needs to handle a file within > different threads it has to protect its multi-threaded usage with an > own lock!
Actually, this problem occurs even if you don't use the same APR file from the second thread. Say you have a thread that is just about to close an APR file using apr_file_close(). It gets interrupted just after call to close(). So, file->filedes is not -1, but the file is closed. Then another thread gets scheduled and opens a new file (using just open(), not APR) and gets an FD that is exactly equal to file->filedes. Now, the first thread, the one using APR file, in the signal handler that interrupted it, calls apr_file_os_get() on that file. It gets back the FD from the second thread! That is a problem that no locking of APR file can solve. Any action on this FD will do things to the file from the second thread, not from this one (because it's already closed). But, by setting file->filedes to -1 before the close(), we can at least mitigate the consequences of such a situation. -- Bojan
