Now that we have a generic listen-on-a-socket mechanism, there's no
longer any reason to have a separate listen-on-a-socket implementation
in http.c.
This also lets us use IOCP and AcceptEx() when they're enabled.
Possibly, we should have a new mechanism to add a socket given only a
listener.
This was as simple as using bufferevent_connect_hostname instead of
calling connect() ourself, which already knows how to use an
evdns_base if it gets one.
Untangling the bind code might be a little trickier.
Others may remain. I wasn't able to get gcc --std=c89 to build libevent
at all, so I don't know what compiler the original reporter is using here.
Note that this change requires us to disable the part of our rpc code
that uses variadic macros when using a non-gcc compiler. This is a
problem if we want our rpc api to be portable.
svn:r1231
a) this is 2009
b) niels and nick have been comaintainers for a while
c) saying "all rights reserved" when you then go on to explicitly
disclaim some rights is sheer cargo-cultism.
svn:r1065
Note that evhttp_hostportfile is not threadsafe, and so its usage will change. Mark its first argument const. Remove a now-redundant declaration for it in http-internal.h.
svn:r743
using evhttp_new, it is possible to associate an event_base with
the http server so that multi-threaded applications can have their
own http server per thread; add appropriate testing.
svn:r397
i applied some bug fixes and slight re-arranged the logic
on when to call the close notification callback;
i also don't like the streaming interface; i'd rather
see it do the chunked response formatting explicitly.
svn:r298
