On Dec 22, 2007, at 5:31 AM, Marc Lehmann wrote:

No. Warnings are warnings, and every compiler has different ones and
different tastes. If you know how to silence those warnings a) without
introducing slowdowns and b) on every compiler, then I would like to hear
about them.


Here's some pretty minor changes (both inline and attached; my mail client tends to bork inline patch formatting):

1. Only instantiate the have_monotonic variable #if EV_USE_MONOTONIC (have_monotonic's usage seems to be protected by EV_USE_MONOTONIC)

2. Only declare infy_fork() #if EV_USE_INOTIFY (infy_fork()'s definition is surrounded by #if EV_USE_INOTIFY)

One more issue that I was not sure about: in ev.h, when EV_MULTIPLICITY, ev_default_loop() is defined as:

static struct ev_loop *
ev_default_loop (unsigned int flags) { ... }

Should that function be marked as inline? That might result in a slight speedup on some platforms if the function is actually inlined. Additionally, it would remove a -Wall warning about ev_default_loop() being defined but not used in files that don't call it. Same goes for ev_now() in the !EV_MULTIPLICITY case.

Thanks.

--
Jeff Squyres
Cisco Systems

Index: ev.c
===================================================================
RCS file: /schmorpforge/libev/ev.c,v
retrieving revision 1.195
diff -u -r1.195 ev.c
--- ev.c        22 Dec 2007 11:44:51 -0000      1.195
+++ ev.c        22 Dec 2007 12:39:05 -0000
@@ -284,7 +284,9 @@

/* sig_atomic_t is used to avoid per-thread variables or locking but still */ /* giving it a reasonably high chance of working on typical architetcures */
+#if EV_USE_MONOTONIC
static sig_atomic_t have_monotonic; /* did clock_gettime (CLOCK_MONOTONIC) work
? */
+#endif

 #ifdef _WIN32
 # include "ev_win32.c"
@@ -1119,7 +1121,9 @@
   backend = 0;
 }

+#if EV_USE_INOTIFY
 void inline_size infy_fork (EV_P);
+#endif

 void inline_size
 loop_fork (EV_P)


Attachment: libev-monotonic-infy-fork.patch
Description: Binary data


_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to