On Fri, 18 Jan 2008, Ruediger Pluem wrote:

Which is why it doesn't scale with large files, and I hacked it to do that to be usable with DVD images on ftp.acc.umu.se (http://issues.apache.org/bugzilla/show_bug.cgi?id=39380 - you might remember the first try to merge some of it). Yes, it has its flaws, but it solves the problem for us. I think that some people has tried it in a proxy setting too with pretty OK result. But this was really off-topic ;)

Getting to the point, I share Brians concerns with going async just for the async sake, for similar reasons:

- People are having problems with making modules even thread safe (see mod_example), forcibly adding async to the mix will raise the bar even higher for people who needs to whip up a simple module. - Callback semantics are messy when they go wrong, debugging can be a pain. - Threads are rather cheap, even on linux since the advent of NPTL. - Performance benefits are unclear.

Given that, there are obvious optimisations that can be, and have been, made. The ones in trunk aimed at not hogging a worker thread for simply writing the remaining data to the client for example. From what I've understood this class of changes doesn't really affect modules.

Also, if there is a way of adding async having it optional in modules then I see no problem with adding it as long as there are cases where it actually helps, other than adding it to the supported buzzwords list ;)