rbb@rkbloom.net wrote:
>Even better than that would be to fix APR so that it registers the proper
>cleanups in this case. This still confuses me though. The problem that
>is being reported, is that we are closing the file twice. Once by the
>cleanup that APR registers, and once by the cleanup that SVN registers.
>So, what exactly is the SVN cleanup supposed to be doing? The APR cleanup
>seems to be closing the file correctly, otherwise their wouldn't be a bug
>report.
>
>
APR is doing everything right. I'll try to explain again what's happening:
On Windows, the C runtime library contains a mapping between POSIX-like
(int) file descriptors and Win32 file handles (which are effectvely
opaque poitners). It does this to maintain a (marginally) POSIX-like
environment for C programs. When you call open() on Windows, two things
happen: first, the runtime creates a Win32 file handle; next, it finds
an available slot in its fd table and returns its index. Conversely,
when you close() a fd, it frees the slot _and_ closes the underlying
Win32 handle.
Now, Neon uses the POSIX-like file I/O layer internally. This is
obviously not optimal, but it's portable. So we have to pass a fd, not a
HANDLE, to neon when calling ne_set_response_body_fd. We use the
runtime's _open_osfhandle function to assign a fd to the file handle
that APR uses internally (APR, of course, uses the Win32 handles directly).
That's all fine as far as it goes; but unfortunately, there's no
function to _un_assign a fd from it's handle. Remember, _open_osfhandle
doesn't acutlaly create a new handle, it just reserves a slot in the
runtime's fd table for an existing handle. Then, when we call close() to
free that fd, the underlying handle gets closed, too; which is bad,
because APR closes that file, too. Ouch.
Of course, we can't just leave the fd floating around, because those are
a _very_ scarce resource (each process only gets about 20 of them in the
MSVC 6.0 runtime, IIRC).
The ideal solution would be for Neon to have a pull interface, so that
instead of giving it a file descriptor, we'd give it a callback that
would read the data from wherever it's stored. Then we wouldn't have to
fiddle with the C runtime's file descriptors at all, we'd just create a
SVN stream that Neon could pull the data from.
In the absence of this solution, creating a duplicate handle seems the
safest way to avoid that bug.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 2 20:32:44 2003