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
On Sat, 2010-03-13 at 17:54 +0200, Graham Leggett wrote:
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
Probably the safe thing to do. Probably won't get many hits, but
nevertheless.
--
Bojan
On Fri, 2010-03-12 at 13:30 +, Joe Orton wrote:
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
On 3/13/2010 9:54 AM, Graham Leggett wrote:
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
On 3/13/2010 5:44 PM, Bojan Smojver wrote:
On Fri, 2010-03-12 at 13:30 +, Joe Orton wrote:
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
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
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
On 3/9/2010 5:52 AM, Graham Leggett wrote:
On 09 Mar 2010, at 1:46 PM, Jeff Trawick wrote:
Hmmm - in that case it may make sense to drop the ifdef entirely,
and if a
unix platform is found to not support O_BLOCK, we can then make a
call then
as what to do. The ifdef could in theory be
On 08 Mar 2010, at 10:53 PM, Jeff Trawick wrote:
Hmmm, the existing code follows this pattern, as below, and if we
decide to
change the pattern then we need to change this behaviour throughout
the rest
of the code, and probably the rest of APR too.
For APR_FOPEN_NONBLOCK, if the caller
On 09 Mar 2010, at 1:46 PM, Jeff Trawick wrote:
Hmmm - in that case it may make sense to drop the ifdef entirely,
and if a
unix platform is found to not support O_BLOCK, we can then make a
call then
as what to do. The ifdef could in theory be solving a problem we
don't have.
I mis-worded
On 08 Mar 2010, at 12:54 AM, Jeff Trawick wrote:
On Sun, Mar 7, 2010 at 10:24 AM, minf...@apache.org wrote:
Author: minfrin
Date: Sun Mar 7 15:24:36 2010
New Revision: 920017
URL: http://svn.apache.org/viewvc?rev=920017view=rev
Log:
Backport r920016:
Enable platform specific support for the
On Mon, Mar 8, 2010 at 9:59 AM, Graham Leggett minf...@sharp.fm wrote:
On 08 Mar 2010, at 12:54 AM, Jeff Trawick wrote:
On Sun, Mar 7, 2010 at 10:24 AM, minf...@apache.org wrote:
Author: minfrin
Date: Sun Mar 7 15:24:36 2010
New Revision: 920017
URL:
On Mon, Mar 08, 2010 at 03:53:42PM -0500, Jeff Trawick wrote:
On Mon, Mar 8, 2010 at 9:59 AM, Graham Leggett minf...@sharp.fm wrote:
...
#if APR_HAS_LARGE_FILES defined(_LARGEFILE64_SOURCE)
oflags |= O_LARGEFILE;
#elif defined(O_LARGEFILE)
if (flag APR_FOPEN_LARGEFILE) {
On Sun, Mar 7, 2010 at 10:24 AM, minf...@apache.org wrote:
Author: minfrin
Date: Sun Mar 7 15:24:36 2010
New Revision: 920017
URL: http://svn.apache.org/viewvc?rev=920017view=rev
Log:
Backport r920016:
Enable platform specific support for the opening of a file or
pipe in non blocking
On 3/7/2010 4:54 PM, Jeff Trawick wrote:
On Sun, Mar 7, 2010 at 10:24 AM, minf...@apache.org wrote:
Author: minfrin
Date: Sun Mar 7 15:24:36 2010
New Revision: 920017
URL: http://svn.apache.org/viewvc?rev=920017view=rev
Log:
Backport r920016:
Enable platform specific support for the
15 matches
Mail list logo
