Re: [gnet] [PATCH] Avoid zero watch condition



Ah, great.  We've had other problems with the Glib event loop too - see
bug 11059 (or the GNet BUGS file).  GConn was also meant as a
work-around, so this is a good thing to fix.

David

(Andy - thanks for committing the patch.)


On Mon, 2004-01-12 at 14:19, Andreas Rottmann wrote:
> Hi!
> 
> I discovered a strange behaviour with my application that uses gnet:
> On certain conditions, its CPU usage would go up to 100% (that
> conditions being related to a GConn connection handler not invoking
> gnet_conn_write() or gnet_conn_read*()). However, the following patch
> (against 2.0.4) fixes the issue, by not making REMOVE_WATCH re-adding
> watches with an empty condition (which, as one might argue, should
> either cause GLib issue a warning or be a no-op instead of causing its
> mainloop to go in CPU-burn-mode).
> 
> The three-line patch:
> 
> --- gnet-2.0.4.orig/src/conn.c	2003-02-25 21:19:15.000000000 +0100
> +++ gnet-2.0.4/src/conn.c	2004-01-12 19:58:45.000000000 +0100
> @@ -42,7 +42,9 @@
>      (C)->watch_flags &= ~(FLAG);			\
>      if ((C)->iochannel) {				\
>        if ((C)->watch) g_source_remove ((C)->watch);	\
> -      (C)->watch = g_io_add_watch ((C)->iochannel, (C)->watch_flags, async_cb, (C)); \
> +      (C)->watch = (C)->watch_flags ? g_io_add_watch ((C)->iochannel, \
> +                                                      (C)->watch_flags, \
> +                                                      async_cb, (C)) : 0; \
>   }}} while (0)
>  
>  #define UNSET_WATCH (C, FLAG)
> 
> 
> Would be nice if that went into 2.0.5.
> 
> Thanks, Andy
-- 
David Helder - dhelder gizmolabs org - http://www.gizmolabs.org/~dhelder




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]