kc3-lang/libevent/bufferevent.c

Branch :


Log

Author Commit Date CI Message
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.
215e629c 2010-06-21 12:26:21 Add bufferevent_lock()/bufferevent_unlock() Although bufferevent operations are threadsafe, sometimes you need to make sure that a few operations on a single bufferevent will all be executed with nothing intervening. That's what these functions are for.
a5208fe4 2010-04-27 13:42:26 Release locks on bufferevents while executing callbacks This fixes a dead lock for me where bufferevents in different event loops use each other and access their input/output buffers (proxy-like scenario).
83986414 2010-03-12 06:04:56 Fix infrequent memory leak in bufferevent_init_common().