----- 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 i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/