Re: [gamin] poll backends are now pluggable



On Wed, Aug 10, 2005 at 03:08:38PM -0400, John McCutchan wrote:
> On Wed, 2005-08-10 at 14:14 -0400, John McCutchan wrote:
> > On Wed, 2005-08-10 at 12:32 -0400, Daniel Veillard wrote:
> > > On Wed, Aug 10, 2005 at 11:41:59AM -0400, John McCutchan wrote:
> > > > My next plan is to remove the consume_subscription nonsense from the
> > > > poll & dnotify backends. I assume these are relics from the days when
> > > > gam_server was threaded.
> > > 
> > >   right, inherited from marmot !
> > > 
> > 
> > It's gone now :) Test suites pass to.
> > 
> > > > I'd also like to rename gam_poll.c/h to gam_poll_dnotify.c/h because it
> > > > really is a dnotify specific poll implementation. Could this be done on
> > > > the CVS server so that we can keep the history?
> > > 
> > >   Hum, I disagree at this point. I think gam_poll.c/h are usable if no
> > > kernel support is configured in, well it should still be usable, and
> > > unless you really want to commit another gam_poll_foo.[ch] then I really
> > > don't see the urgency of that change.
> > 
> > Well the current gam_poll has code that was written with dnotify in
> > mind. I would like to add a gam_poll_basic.[ch] which is a very simple
> > poll backend. I don't have the code ready, but I would like to do it
> > soon.
> 
> Replying to myself. If you look at gam_poll, there are two modes of
> operation depending on whether or not dnotify is running.
> 
> gam_poll installs one of two main loop callbacks:
> 
> gam_poll_scan_callback - used when dnotify is enabled -- scans only the
> missing and busy lists.
> 
> gam_poll_scan_all_callback - used when dnotify isn't enabled. -- scans
> all_resources.
> 
> Since these are very different beasts, I think we should have them
> seperated like so:
> 
> gam_poll_generic.[ch] -- generic stuff from gam_poll.[ch]
> 
> gam_poll_dnotify.[ch] -- dnotify specific stuff -- flow control,
> gam_poll_scan_callback.
> 
> gam_poll_basic.[ch] -- gam_poll_scan_all_callback.

  okay for the big split on principle grounds. In practice it means 
making sure the various combinatons still work, it happens that kernel
monitoring just doesn't work for specific platform reasons. I also
hope it won't affect the BSD/Mach based modules but if my memory is
right they didn't use gam_poll.

> We could do CVS surgery, or I could just add those new files, removing
> the code from gam_poll.[ch] as I move it into it's submodule.
> 
> What do you think?

  I think it's actually cleaner to do a proper cvs delete/add to maintain
consistency of history revisions. Not that I expect to go back but you never
know I may have to maintain a 0.1.1 based branch for 6 years :-\

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



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