bufferevent.c

Branch :

Log

Commit	Date	Message
3c824bd3	2011-10-24 13:18:09	Update copyright dates to 2011.
e6af35d7	2011-08-24 21:39:28	Correctly terminate IO on an async bufferevent on bufferevent_free
5dc56628	2011-02-24 12:30:40	Workaround libevent bug https://sourceforge.net/tracker/index.php?func=detail&aid=3078187&group_id=50884&atid=461324 The problem is that bufferevent_disable() doesn't disable EV_WRITE when 'connecting' flag is set. However from evhttp_connection_reset() we want to disable EV_WRITE for sure (we are closing the socket next). So we add bufferevent_disable_hard(), which acts like bufferevent_disable(), but resets 'connecting' flag before the call to the actual handler. TODO: bufferevent_disable_hard() shouldn't be public, remove it from event2/bufferevent.h.
aab49b60	2010-10-21 14:04:24	Add a bufferevent_get_base function
ac27eb82	2010-10-08 00:59:02	Correct logic on disabling underlying bufferevents when disabling a filter Previously, whenever writing was disabled on a bufferevent_filter (or a filtering SSL bufferevent), we would stop writing on the underlying bufferevent. This would make for trouble, though, since if you implemented common patterns like "stop writing once data X has been flushed", your bufferevent filter would disable the underlying bufferevent after the data was flushed to the underlying bufferevent, but before actually having it written to the network. Now, we have filters leave their underlying bufferevents enabled for reading and writing for reading and writing immediately. They are not disabled, unless the user wants to disable them, which is now allowed. To handle the case where we want to choke reading on the underlying bufferevent because the filter no longer wants to read, we use bufferevent_suspend_read(). This is analogous to the way that we use bufferevent_suspend_write() to suspend writing on a filtering bufferevent when the underlying bufferevent's output buffer has hit its high watermark.
040a019f	2010-09-09 17:19:20	Obey enabled status when unsuspending
17a14f1a	2010-09-01 11:04:57	Only process up to MAX_DEFERRED deferred_cbs at a time. If threads queue callbacks while event_process_deferred_callbacks is running, the loop may spin long enough to significantly skew timers. A unit test stressing this behavior is also in this commit.
da6e7cd4	2010-08-17 13:26:03	Correctly detect failure to delete bufferevent read-timeout event Gilad Benjamini noted that we check the error code for deleting a write-timeout event twice, and the read timeout not at all. This shouldn't be a bit problem, since it's really hard for a delete to fail on a timeout-only event, but it's worth fixing. Fixes bug 3046787
0bffe43a	2010-08-09 12:08:40	Fix a nasty dangling-event bug when using rate-limiting groups When we freed a bufferevent that was in a rate-limiting group and blocked on IO, the process of freeing it caused it to get removed from the group. But removing the bufferevent from the group made its limits get removed, which could make it get un-suspended and in turn cause its events to get re-added. Since we would then immediately _free_ the events, this would result in dangling pointers. Fixes bug 3041007.
ec347b92	2010-07-07 16:45:03	Move event-config.h to include/event2 This change means that all required include files are in event2, and all files not in event2/* are optional.