apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r920017 - in /apr/apr/branches/1.4.x: ./ file_io/unix/open.c include/apr_file_io.h
Date Sun, 14 Mar 2010 02:01:26 GMT
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 forced to have "if windows do this, if
> unix do that". This is APR's job, not the job of the application using APR.

You are aboslutely right; whatever goes into the apr_file api for nonblocking
file behavior must be portable, work consistently and produce identical results
on all platforms.  What I think Joe (and I) have been suggesting is that this
API does not look thought out from the perspective you have identified above.

> My understanding is that these are well understood under unix, are there
> unix platforms out there that *don't* support non blocking behaviour?

It is not surprising how distinct the BSD, Linux and Solaris "standard"
behaviors are; why else does virtually every die-hard APR developer rely
on a copy of Stevens "Unix Network Programming" on the shelf?

> 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).

Why would we?  I'm under the impression that file I/O completion had
existed on WindowsNT for about 2 decades.  It need not block.  Now define
nonblocking behavior, and we are all set.  I suspect that the entire unix
file read/write set of API's, including write_complete etc, need to be
reviewed in light of the introduction of this flag.

I guess I'm perceiving this as throwing a unix feature at APR to see if
it sticks, and I'm not fond of that approach to such junk expansion of APR.

View raw message