From owner-freebsd-arch@freebsd.org Sun Oct 29 17:03:52 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A45D8E471CC for ; Sun, 29 Oct 2017 17:03:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E06DE84EBC for ; Sun, 29 Oct 2017 17:03:51 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 21d9b00a-bccb-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 21d9b00a-bccb-11e7-a893-25625093991c; Sun, 29 Oct 2017 17:03:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9TH3iiK001491; Sun, 29 Oct 2017 11:03:44 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1509296624.21609.24.camel@freebsd.org> Subject: Re: Allow faster eventhandler dispatching by keeping pointers to handler lists. From: Ian Lepore To: Matt Joras , "freebsd-arch@FreeBSD.org" Date: Sun, 29 Oct 2017 11:03:44 -0600 In-Reply-To: <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> References: <1509243567.56824.103.camel@freebsd.org> <3a71dd31-99cb-c891-9d52-a7f2e7010011@FreeBSD.org> <1509293552.21609.5.camel@freebsd.org> <1509294247.21609.12.camel@freebsd.org> <7b59ff3d-3458-0bca-e6b4-13454b13efb0@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 17:03:52 -0000 On Sun, 2017-10-29 at 09:38 -0700, Matt Joras wrote: > On 10/29/2017 09:24, Ian Lepore wrote: > > > > On Sun, 2017-10-29 at 10:12 -0600, Ian Lepore wrote: > > > > > > Actually, it looks like we've done nearly identical work, modulo some > > > minor naming differences (that I'm completely agnostic about), and you > > > have the EHL_NONEMPTY flag that didn't occur to me until after I > > > created the phab review last night. > > > > > > The other big difference is that mine still links the fast/static lists > > > into the global list-of-lists, to preserve what I call "late loose > > > binding" where an event handler can register for events before the > > > event provider is present (picture a module that monitors events which > > > gets loaded before a module that produces those events). > > > > > > It ocurred to me this morning that an optimization for mine would be to > > > place any list created by eventhandler_create_list() at the end of the > > > global list, on the theory that it will mostly be accessed directly via > > > pointer and the items at the head of the global list should be the ones > > > more likely to be searched by name. > > > > > > -- Ian > > Oops, I apparently overlooked _eventhandler_insert_static() in your > > changes.  I think if that were changed to first check whether the new > > handler list already exists on the global list, our changes really > > would be essentially identical. > > > > -- Ian > Indeed. The other difference I noted is that my version > statically-allocates the actual list structs, and relies on static > initialization, whereas yours uses malloc and initializes them explicitly. > > How would you like to proceed? > > Matt > Oh.  Right.  Hmmm, I think malloc() is required to support the case where a handler registers before the static list init is invoked, and I do think that's a useful feature to preserve.  That means the lists aren't really static, though, which then makes STATIC a bit out of place in the new function/macro names. >From my version of the changes, I really liked then names EVENTHANDLER_DEFINE_LIST() and EVENTHANDLER_DECLARE_LIST() because they so exactly say what they do.  On the other hand, I hate EVENTHANDLER_INVOKE_LIST(), I just couldn't think of anything better.  I considered FAST where LIST appears, playing off the existing 'slow' comments, but it seems to somehow imply the handlers themselves are different or faster, which is all wrong. -- Ian