apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r920017 - in /apr/apr/branches/1.4.x: ./ file_io/unix/open.c include/apr_file_io.h
Date Fri, 12 Mar 2010 13:30:12 GMT
On Tue, Mar 09, 2010 at 12:26:08PM +0200, Graham Leggett wrote:
> On 08 Mar 2010, at 11:26 PM, Joe Orton wrote:
> 
> >APR_FOPEN_LARGEFILE is intended to be (and is documented as)
> >"advisory"
> >rather than mandatory.
> >
> >Exposing a NONBLOCK flag without attaching *any* semantics to it
> >w.r.t.
> >subsequent read/write calls seems completely wrong.  If you want
> >platform-specific behaviour and don't care how badly it interacts with
> >other apr_file_* interfaces then use native open() and
> >apr_os_file_put()
> >to get the APR wrapper.
> 
> This makes no sense at all.
> 
> If I open a file using native open() setting flags appropriately,
> and then use apr_os_file_put(), followed by apr_file_read and
> apr_file_write, how is that in any way different to using
> apr_file_open(), setting flags appropriately, and then follow with
> apr_file_read and apr_file_write?

Well, right, this the point I was making - it should be no different at 
run-time; i.e. you can achieve exactly what you want already without 
adding a new interface which uses up one of the remaining bits in the 
APR_FOPEN_* bitmask, must be maintained in perpuity, won't work on 
platform X and hence confuses users, etc etc.

But specifically, if I'm writing an app which depends on being able to 
do non-blocking IO to a fifo, I *need* the API guarantee that O_NONBLOCK 
works.  You can get that with open()+apr_os_file_put(), but you can't 
get that with the API added to APR, which has no such guarantee.  So 
from that perspective, adding _NONBLOCK to APR is little use.

To be clear; I don't see a problem with adding new flags so long as they 
come with documented API constraints/guarantees.  It's the idea of 
adding a seemingly deliberately undocumented platform-specific flag 
which seems wrong.  Does that make more sense?

> Are there specific semantics you are referring to, or are you just
> assuming they are missing? In the case of read and write,
> APR_STATUS_IS_EAGAIN already gives you the semantics you want. Or
> are you referring to something else?

I'd expect to see some description of exactly what the new APR_FOPEN_* 
flag changes w.r.t. method calls; does it affect just read/write, what 
about flush, sync, etc? Can I presume POSIX semantics w.r.t. O_NONBLOCK 
in open()?  The questions are kind of endless if the documentation isn't 
there.

Regards, Joe

Mime
View raw message