Branch :
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
| 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. | ||
| 74871cac | 2009-11-09 19:37:27 | Change event_base.activequeues to "array of eventlist". Previously, event_base.activequeues was of type "array of pointers to eventlist." This was pointless: none of the eventlists were allowed to be NULL. Worse, it was inefficient: - It made looking up an active event queue take two pointer deferences instead of one, thus risking extra cache misses. - It used more RAM than it needed to, because of the extra pointer and the malloc overhead. Also, this patch fixes a bug where we were saying calloc(N,N*sizeof(X)) instead of calloc(N,sizeof(X)) when allocating activequeues. That part, I'll backport. Also, we warn and return -1 on failure to allocate activequeues, rather than calling event_err. svn:r1525 | ||
| ab96b5f3 | 2009-11-09 18:30:33 | Add an option to disable the timeval cache. svn:r1518 | ||
| 693c24ef | 2009-11-09 17:16:30 | Implement queued timeouts for case where many timeouts are the same. Libevent's current timeout code is relatively optimized for the randomly scattered timeout case, where events are added with their timeouts in no particular order. We add and remove timeouts with O(lg n) behavior. Frequently, however, an application will want to have many timeouts of the same value. For example, we might have 1000 bufferevents, each with a 2 second timeout on reading or writing. If we knew this were always the case, we could just put timeouts in a queue and get O(1) add and remove behavior. Of course, a queue would give O(n) performance for a scattered timeout pattern, so we don't want to just switch the implementation. This patch gives the user the ability to explicitly tag certain timeout values as being "very common". These timeout values have a cookie encoded in the high bits of their tv_usec field to indicate which queue they belong on. The queues themselves are each triggered by an entry in the minheap. See the regress_main.c code for an example use. svn:r1517 |