I concur.
On Tue, 2015-04-07 at 15:56 -0700, Thiago Macieira wrote:
> On Tuesday 07 April 2015 15:23:24 Keane, Erich wrote:
> > Our biggest CPU intensity currently is watching the ethernet/wifi
> > adapters for change and JSON parsing/generation. Otherwise we are
> > pretty low-hit.
>
> In an ideal world, "watching" should not be CPU intensive. It should require
> exactly 0 cycles in user-space to watch: you call select(2) or poll(2) or
> equivalent, then sleep until something of interest happens. Anything that
> requires spending CPU time is a flawed design.
>
> In real world, we have to put up with flawed APIs from libraries we use. I
> don't know if Linux netlink supports watching for configuration changes.
>
> > I agree that a solid audit to remove a bunch of the threading would be a
> > great feature as well, but I suspect that SOME threading would be
> > necessary, but it could definitely make the glib2 less necessary.
>
