apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: apr_file_close()/apr_socket_close()
Date Fri, 30 Oct 2009 12:02:53 GMT
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


Mime
View raw message