Re: [gamin] poll backends are now pluggable
- From: John McCutchan <ttb tentacle dhs org>
- To: veillard redhat com
- Cc: gamin-list gnome org
- Subject: Re: [gamin] poll backends are now pluggable
- Date: Thu, 11 Aug 2005 10:32:36 -0400
On Wed, 2005-08-10 at 17:25 -0400, Daniel Veillard wrote:
> 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.
>
The only current user of gam_poll is dnotify. Inotify, Kqueue, and Hurd
don't make use of it.
> > 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 :-\
Okay.
--
John McCutchan <ttb tentacle dhs org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]