apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: Regarding apr_file_writev() and locking...
Date Mon, 14 May 2007 12:54:10 GMT
Joe Orton wrote:
> On Fri, May 11, 2007 at 10:38:01PM -0300, Davi Arnaut wrote:
>> The patches improves the locking interaction with buffering. But, quite
>> frankly, the unix file_io locking and buffering is a bit messed. There
>> is no clear indication which functions are protected by APR_XTHREAD,
>> checks for partial writes on flushing are missing, buffering and file
>> positioning don't play well together, et cetera.
> 
> I don't disagree that the existing buffering/mutex stuff is a mess, but 
> nested mutexes are not available on all platforms, so they can't be 
> relied upon.

Pools also use nested mutexes. So, I guess those platforms need to be
fixed. BTW, which platforms that use unix/file_io don't support nested
mutexes?

For now I think we can create a file_flush_locked function.

>> I am in the middle of writing a patch that converts all file_io to
>> standard i/o functions (stdio/streams) so we can remove all code
>> involving buffering, file positioning and even locking at some cases. It
>> saves a huge amount of code lines, and I hope, gives fewer bugs.
> 
> A notable Unix platform has a crippled stdio implementation (32-bit 
> Solaris), so this probably doesn't really fly either.

Another option is to split locking, buffering and i/o into separate
layers. Locking and buffering would be platform-agnostic.

A similar (yet much simpler) mechanism like the apache filters. This
also can save us a lot of trouble, since each port (unix/win32/os2) of
file_io has it's own implementation of buffering and locking, but yet
they are the same.

--
Davi Arnaut

Mime
View raw message