Re: [gamin] gam-poll.c rewrite

["Neal H. Walfield" <neal walfield org>]

>   Might be.
>   You still increase the number of watched resources and potentially
> a lot.

In the worst case, maybe.  But I think the worst case is rather
pathological: many distant leaf monitors with / as their pair-wise
common ancestor.

> This really can have a large impact and it's very hard to assess
> how many things will break. Things do break on changes, no matter if
> this is right or wrong to do the change, and gamin potentially affects
> a lot of desktop applications and expected user behaviour. Adding monitors
> to the full hierarchy is taking a lot of risks IMHO.

It sounds to me like there is something more you wan to say here.
Otherwise it seems to me anything that self-describes as a rewrite is
high risk.

>   My view about this is "Open Source is a process", that process means to
> operate as a team, in an open fashion, and pushing big changes like the
> recursive monitoring should never be done silently. If you do so, you break
> the knowledge of every other people in that team, reducing the value of the
> code in the end, even if intrinsically the code may be better after that.

I tried to summarize the changes this patch introduces in the mail
accompanying the patch.  Of course, it is only summary and I
encourage you to study the patch.

> > The debugging API exposes implementation details.  If the
> 
>   Those implementation details are crucially important. If I get a Changed
> even because I watched using dnotify versus because watching with poll it
> is very different, this may meen the busy detection code in the server just
> failed. I also want to monitor that there is no leak of kernel monitors
> from the regression tests because that means leaks of filedescriptors and
> potentially filling hard drives with unreachables but still open files.

I'm rather confused.  It makes sense that the implementation is sound
and that we should somehow check that.  I don't see why exposing the
implementation details are crucially important.  It seems like
documentation: documentation which is far away from the code is rarely
updated which is, I think, why you use a documentation extractor.  It
seems the same logic applies to implementation assertions.