Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4AEAF435.1060000@ruppert-it.de>
Date: Fri, 30 Oct 2009 15:12:05 +0100
From: Stefan Ruppert <ml@ruppert-it.de>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
MIME-Version: 1.0
To: Bojan Smojver <bojan@rexursive.com>
CC: APR Development List <dev@apr.apache.org>
Subject: Re: apr_file_close()/apr_socket_close()
References: <1256883239.2488.54.camel@shrek.rexursive.com>
	 <4AEAB13F.3000804@ruppert-it.de>
	 <1256896115.2488.67.camel@shrek.rexursive.com>
	 <4AEAC79B.3010906@ruppert-it.de>
 <1256904174.2488.73.camel@shrek.rexursive.com>
In-Reply-To: <1256904174.2488.73.camel@shrek.rexursive.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bojan Smojver wrote:
> 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.
> 

Ok, I got your point. It is not a threading issue. Its a signal handler 
issue. For that purpose your proposal works just fine.

Stefan