[PATCH] inotify extension: Better implementation of the event string representation

Matt Mackall mpm at selenic.com
Fri Jun 18 13:11:47 CDT 2010


On Fri, 2010-06-18 at 12:43 -0300, Renato Cunha wrote:
> hgext/inotify/linux/_inotify.c |  63 ++++++++++++++++++++++++++----------------
>  1 files changed, 39 insertions(+), 24 deletions(-)
> 
> 
> # HG changeset patch
> # User Renato Cunha <renatoc at gmail.com>
> # Date 1276875647 10800
> # Node ID 4b4edacbefcbfebb6fae348492c701380f083444
> # Parent  36984edd907d89085d463765ed39d69665d5944e
> inotify extension: Better implementation of the event string representation.
> 
> This patch reimplements the event_repr function. It got mostly rewritten to
> eliminate the need for conditional compilation of the module when building in
> py3k. The trick there (thanks to Antoine Pitrou) is to use the % operator to
> let the python interpreter format the string to be returned.
> 
> diff --git a/hgext/inotify/linux/_inotify.c b/hgext/inotify/linux/_inotify.c
> --- a/hgext/inotify/linux/_inotify.c
> +++ b/hgext/inotify/linux/_inotify.c
> @@ -335,11 +335,24 @@
>  	int wd = PyInt_AsLong(evt->wd);
>  	int cookie = evt->cookie == Py_None ? -1 : PyInt_AsLong(evt->cookie);
>  	PyObject *ret = NULL, *pymasks = NULL, *pymask = NULL;
> -	PyObject *join = NULL;
> +	static PyObject *join = NULL;
>  	char *maskstr;
> +	PyObject *tuple = NULL, *formatstr = NULL;
> +	static PyObject *er_wm = NULL, *er_wmc = NULL;
> +	static PyObject *er_wmn = NULL, *er_wmcn = NULL;
>  
> -	join = PyString_FromString("|");
> -	if (join == NULL)
> +	if (!join)
> +		join = PyString_FromString("|");
> +	if (!er_wm)
> +		er_wm = PyString_FromString("event(wd=%d, mask=%s)");
> +	if (!er_wmn)
> +		er_wmn = PyString_FromString("event(wd=%d, mask=%s, name=%s)");
> +	if (!er_wmc)
> +		er_wmc = PyString_FromString("event(wd=%d, mask=%s, cookie=0x%x)");
> +	if (!er_wmcn)
> +		er_wmcn = PyString_FromString("event(wd=%d, mask=%s, cookie=0x%x, name=%s)");

I hadn't realized these were static. But still, most of these tests and
null initializers[1] are redundant. If join isn't set, all of them will
need allocating. 

It'd be better to do this at module load time with globals though.
Simpler, no per-call tests, and no delayed failure.

[1] Initializing a static object to NULL takes up space in the DATA
segment, whereas uninitialized static objects are already put in the BSS
section and -filled with zeros at program startup-.

As this stuff all has zero impact on the 1.6 functionality and the code
freeze is started, I'm going to drop this stuff for now. We'll try to
get you merged up shortly after release.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list