event-internal.h

Branch :

Log

Commit	Date	Message
cb670740	2010-04-28 11:51:56	Make debug mode catch mixed ET and non-ET events on an fd Of the backends that support edge-triggered IO, most (all?) do not support attempts to mix edge-triggered and level-triggered IO on the same FD. With debugging mode enabled, we now detect and refuse attempts to add a level-triggered IO event to an fd that already has an edge-triggered IO event, and vice versa.
b557b175	2010-03-21 13:28:48	Detect and refuse reentrant event_base_loop() calls Calling event_base_loop on a base from inside a callback invoked by that same base, or from two threads at once, has long been a way to get exceedingly hard-to-diagnose errors. This patch adds code to detect such reentrant invocatinos, and exit quickly with a warning that should explain what went wrong.
cdd4c490	2010-03-11 00:38:46	Try to comment some of the event code more
17efc1cd	2010-03-04 01:25:51	Update all our copyright notices to say "2010"
23170a69	2010-02-25 16:57:57	Fix mingw compilation
4faeaea9	2010-02-19 03:39:50	Clean up formatting: function/keyword spacing consistency. - Keywords always have a space before a paren. Functions never do. - No more than 3 blank lines in a row.
e5bbd40a	2010-02-18 17:41:15	Clean up formatting: use tabs, not 8-spaces, to indent.
a66e947b	2010-01-25 13:44:56	Use less memory for each entry in a hashtable Our hash-table implementation stored a copy of the hash code in each element. But as we were using it, all of our hash codes were ridiculously easy to calculate: most of them were just a matter of a load and a shift. This patch lets ht-internal be built in either of two ways: one caches the hash-code for each element, and one recalculates it each time it's needed. This patch also chooses a slightly better hash code for event_debug_entry.
cd17c3ac	2010-01-22 00:34:37	Add support for a "debug mode" to try to catch common errors. Right now it only catches cases where we aren't initializing events, or where we are re-initializing events without deleting them first. These are however shockingly common.
27308aae	2010-01-14 16:30:40	Changelist code to defer event changes until just before dispatch This is necessary or useful for a few reasons: 1) Sometimes applications will add and delete the same event more than once between calls to dispatch. Processing these changes immediately is needless, and potentially expensive (especially if we're on a system that makes one syscall per changed event). Yes, this actually happens in practice for nonpathological code, such as in cases where the user's callback conditionally re-adds a non-persistent event, or where draining a buffer turns off writing and invokes a user callback which adds more data which in turn re-enabled writing. 2) Sometimes we can coalesce multiple changes on the same fd into a single syscall if we know about them in advance. For example, epoll can do an add and a delete at the same time, but only if we have found out about both of them before we tell epoll. 3) Sometimes adding an event that we immediately delete can cause unintended consequences: in kqueue, this makes pending events get reported spuriously.