On 07 Jun 2013, at 2:55 PM, Jim Jagielski <[email protected]> wrote: > Yeah, I think conn_rec would make sense if we were a single-threaded > server, but considering the hybrid that we are, the real thing we're > concerned about are the raw sockets. This also makes more sense > with things like SPDY, iirc.
The reason I had conn_rec in mind wasn't to do with being single threaded, but rather to do with the supporting infrastructure like the logging API, etc taking a conn_rec. What would be less-than-ideal would be if we had a sudden proliferation of interfaces, each module trying to reinvent what conn_rec does. The conn_rec structure doesn't dictate any single threaded behaviour, it just contains metadata about the socket after all, and optionally a link to a filter stack (and the filter stack need not have any single threaded concept either). One thing I did notice - conn_rec contains all sorts of metadata about the socket, but not the apr_socket_t itself, and that isn't cool. Ideally we must fix that. > I also like the "weirdness" of the API (socket grouping)... it's > more robust. > > I really, REALLY like this! ++1 To be clear I really like this too. Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
