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
