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
This is patch 2673214 from mmadia. It is correct, since we unconditionally
include signal.h in many other places, and only sometimes include sys/signal.h.
It is necessary to compile on Haiku, I'm told.
svn:r1228
Previously, we could lose the heap property when we removed an item
whose parent was greater than the last element in the heap. We would
replace the removed item with the last element, and consider shifting
it down, but we wouldn't consider shifting it up.
Patch from Marko Kreen.
svn:r1226
This is exceptionally important with multithreaded stuff, where we use
an event to notify the base that other events have been made active.
If the activated events have a prioirty number greater than that of the
notification event, it will starve them, and that's no good.
svn:r1149
In particular, we don't allow adding any data to end front of inbuf
(we do that when we read), or removing it from the front of outbuf (we
drain data only when we write).
svn:r1144
From the documentation:
Prevent calls that modify an evbuffer from succeeding. A buffer may
frozen at the front, at the back, or at both the front and the back.
If the front of a buffer is frozen, operations that drain data from
the front of the buffer, or that prepend data to the buffer, will
fail until it is unfrozen. If the back a buffer is frozen, operations
that append data from the buffer will fail until it is unfrozen.
We'll use this to ensure correctness on an evbuffer when we're waiting
for an overlapped IO call to finish.
svn:r1143
* Allow the user to set the Content-Length: then stream a reply.
This is useful for large requests of a known size. Added unit test.
* Don't send a response body on HEAD requests, 1xx status codes, 204
status codes, or 304 status codes, as described in RFC 2616 section
4.3. (Doing otherwise causes problems - in particular, if a 304 has a
chunked body (even an empty one), Safari 3.1.1 issues and then fails
the next request on the connection with the non-sequitur error message
"Too many HTTP redirects"!)
* Specify a default Content-Type: when a response body is required, not
when we have data in the response buffer by the time we make the
header. (I.e., do this on evhttp_send_reply_start() for consistency.)
* Don't expect a body in response to HEAD requests.
svn:r898
