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.
