On 12 Mar 2010, at 3:30 PM, Joe Orton wrote:
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?
To zoom out a bit to put this into context, right now APR has no
support for non blocking behaviour at all, and this is the problem I
would like to fix. Using apr_os_file_put(), while functional, isn't
portable, and as a result a user of the API is forced to have "if
windows do this, if unix do that". This is APR's job, not the job of
the application using APR.
Based on what you've written above, the #else ENOTIMPL seems to be the
way to go. If it isn't supported, you get explicit confirmation of the
fact, and the caller can then make a decision as to what to do at that
point (leave out the flag, punt, whatever).
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.
My understanding is that these are well understood under unix, are
there unix platforms out there that *don't* support non blocking
behaviour?
What I'm trying to ascertain is whether we are trying to solve a
problem that isn't there. I'm not convinced we need the ifdef
O_NONBLOCK at all in the unix case.
In the Windows case we can certainly return ENOTIMPL, and the same for
Netware (the Netware people can change that to be otherwise if it
isn't true).
Regards,
Graham
--
