bufferevent_pair.c

Branch :

Log

Commit	Date	Message
56faf02b	2017-04-13 14:58:13	bufferevent: refactor to use type check macros (cherry picked from commit 92cc0b9c3db38088f79c5d1e432c429fbc366968)
28518896	2016-05-21 21:05:11	Fix bufferevent_pair to properly set BEV_EVENT_{READING,WRITING} on flush. Here's some fun. From `bufferevent.h`: ``` #define BEV_EVENT_READING 0x01 /*< error encountered while reading / #define BEV_EVENT_WRITING 0x02 /*< error encountered while writing / ``` And from `event.h`: ``` /** Wait for a socket or FD to become readable / #define EV_READ 0x02 /* Wait for a socket or FD to become writeable */ #define EV_WRITE 0x04 ``` Library users have to be very careful to get this right; it turns out, the library itself got this wrong in the `bufferevent_pair` code. It appears that in most of the code, only `BEV_EVENT_FINISHED` will indicate whether it's read or write; on error or timeout, it appears that "both" is assumed and not set in the callback. I read through all the other places where `BEV_EVENT_FINISHED` is passed to an event callback; it appears that the pair code is the only spot that got it wrong. azat: add TT_FORK to avoid breaking clean env, and rebase commit message (copied from #359) Fixes: #359
f45d39d1	2015-07-24 05:40:59	Fix lock leak in be_pair_flush() if flush type is BEV_NORMAL Fixes: bufferevent/bufferevent_pair_flush_normal $ regress --no-fork bufferevent/bufferevent_pair_flush_normal bufferevent/bufferevent_pair_flush_normal: FAIL ../test/regress_bufferevent.c:181: assert(bufferevent_pair_get_partner(bev1) == NULL): 0x177fa20 vs (nil) [bufferevent_pair_flush_normal FAILED] Fixes #266
92a359ee	2015-01-03 19:37:15	be_pair: release shared lock with the latest of bufferevent_pair Then next code sample will use free'd lock: evthread_use_pthreads(); ... assert(!bufferevent_pair_new(base, BEV_OPT_THREADSAFE, pair)); ... bufferevent_free(pair[0]); # refcnt == 0 -> unlink bufferevent_free(pair[1]); # refcnt == 0 -> unlink ... event_base_free() -> finalizers -> EVTHREAD_FREE_LOCK(bev1->lock) -> BEV_LOCK(bev2->lock) <-- already freed While if you will reverse the order: bufferevent_free(pair[1]); # refcnt == 0 -> unlink bufferevent_free(pair[0]); # refcnt == 0 -> unlink ... event_base_free() -> finalizers -> BEV_LOCK(bev2->lock)/!own_lock/BEV_UNLOCK(bev2->lock) -> EVTHREAD_FREE_LOCK(bev1->lock) (own_lock) It is ok now, but I guess that it will be better to relax order of freeing pairs.
49efac53	2014-02-09 13:35:21	Merge remote-tracking branch 'origin/patches-2.0'
f2428a28	2014-02-09 13:29:26	bufferevent_pair: don't call downcast(NULL)
a7384c78	2013-12-03 23:01:54	Add an option to trigger bufferevent event callbacks
61ee18b8	2013-12-03 22:49:57	Add an option to trigger bufferevent I/O callbacks
02fbf687	2013-04-09 18:16:13	Use finalization feature so bufferevents can avoid deadlocks Since the bufferevents' events are now EV_FINALIZE (name pending), they won't deadlock. To clean up properly, though, we must use the finalization feature. This patch also split bufferevent deallocation into an "unlink" step that happens fast, and a "destruct" step that happens after finalization. More work is needed: there needs to be a way to specify a finalizer for the bufferevent's argument itself. Also, this finalizer business makes lots of the reference counting we were doing unnecessary. Also, more testing is needed.
c0e425ab	2012-05-09 11:06:06	Restore our priority-inversion-prevention code with deferreds Back when deferred_cb stuff had its own queue, the queue was always executed, but we never ran more than 16 callbacks per iteration. That made for two problems: 1: Because deferred_cb stuff would always run, and had no priority, it could cause priority inversion. 2: It doesn't respect the max_dispatch_interval code. Then, when I refactored deferred_cb to be a special case of event_callback, that solved the above issues, but made for two more issues: 3: Because deferred_cb stuff would always get the default priority, it could could low-priority bufferevents to get too much priority. 4: With code like bufferevent_pair, it's easy to get into a situation where two deferreds keep adding one another, preventing the event loop from ever actually scanning for more events. This commit fixes the above by giving deferreds a better notion of priorities, and by limiting the number of deferreds that can be added to the _current_ loop iteration's active queues. (Extra deferreds are put into the active_later state.) That isn't an all-purpose priority inversion solution, of course: for that, you may need to mess around with max_dispatch_interval.