2011/6/18 Igor Galić <i.ga...@brainsware.org>: > > > ----- Original Message ----- >> On Friday 17 June 2011, Graham Leggett wrote: >> > We used openssl to make our non blocking event driven stuff work, >> > and it works really well (once you've properly handled >> > SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE). There is no reason >> > I can see that would stop us using openssl to be async in httpd, >> > we just need to refactor the mod_ssl code to actually do it. >> >> Someone (Paul?) once told me that openssl is not very good when it >> comes to async access to the session cache (which could need network >> io if using memcached), CRLs (which I could imagine to reside in >> LDAP) >> and similar things. But this would have to be evaluated. >> >> > The tricky part with event driven code is the really bad support >> > for event driven file access. We used libev as our core event >> > loop, which does a significant amount of work to make files and >> > sockets work the same way in the event loop as best it can in a >> > portable way. Don't know of any other event loop that does this. >> > It's difficult trying to do the event driven thing if you >> > intersperse event driven socket handling with blocking file >> > handling, you end up with many requests blocked by an unrelated >> > system call. >> >> Yes, I guess we would need a pool of lightweight worker threads that >> does the file io (especially sendfile). Those threads would probably >> get by with very small stack sizes and use little resources. If the >> event library we choose already has this built in, we can of course >> use that, too. > > This kind of reminds me of the architecture of Apache Traffic Server > see http://www.slideshare.net/zwoop/rit-2011-ats >
Yes, ATS is the right model I think, but I don't think the... C++isms and general bagage that comes along with it are ideal for httpd though?
