httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: Should ap_bread et. al. be modified to work with async i/o APIs?
Date Wed, 12 Apr 2000 17:53:26 GMT


On Wed, 12 Apr 2000, Bill Stoddard wrote:

> > On Wed, 12 Apr 2000, Bill Stoddard wrote:
> >
> > > Does it make sense to modify the buff code (ap_bread, et. al) to
> directly
> > > handle async I/O? As Dean mentioned earlier, this requires buf to
> maintain
> > > more state information. Here is the reason I'm asking...
> >
> > it already supports async i/o, are you suggesting to remove that support?
> > i'm not sure what you're saying.
> >
> It supports non-blocking but not async. The difference: a non-blocking read
> will return 0 bytes with a return code to try the read again. Data is not
> read into the buffer until the app attemps the read again. An async read
> returns 0 bytes read but the kernel fills the buffer when it has data,
> regardless of whether app make the next read or not. This completely screws
> up ap_bread() and ap_send_fb().

oh i see...

for now i suggest using a buffer in your iol to receive the async read.

we can eliminate the extra copy some day later ;)

-dean


Mime
View raw message