[gstreamer-bugs] [Bug 350477] [Registry] Provide a way for plugins to delegate the 'changes' behaviour

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Fri Aug 31 03:34:52 PDT 2007


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=350477

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #20 from Tim-Philipp Müller  2007-08-31 10:34 UTC -------
> > The registry cache would need to carry a timestamp for each directory (or even
> > each file?) in order to check for changes.
> 
> For each file unfortunately. I can't see how we can get a fully working system
> with only recording the timestamps of only directories (it might work on
> unix/posix, but I doubt it'll  work on win32).

It depends on how efficient you want to be in the case where there is a change,
ie. with what granularity we should detect a change.  Theoretically, you could
probably get away with just storing one or two cumulative hashes of all
paths/timestamps read; this is very space-efficient, but you'll only know
whether something changed after scanning through all directories and stat'ing
all files.  Or you could store a cumulative timestamp/filename hash for each
directory - then you would know that something changed after you've scanned
that particular directory and don't have to go through the others.  Or you
could store things per-file, then you know something changed as soon as you hit
the first new/removed/changed file.  This is all about optimising the unlikely
case where something actually changed of course, which will be expensive
anyway, since the plugin needs to be loaded, so I'm not sure if we really need
file granularity here.

(My assumption here is that hash collisions are so unlikely that we could get
away with using some sort of simple hash here)


> Tim : I don't think globbing would bring us anything extra, just checking the
> extensions (as we already do to check for plugins using .so,.dll,.dynlib,...)
> of the files should be enough.

That's what I was saying too.  I was just providing a rationale for dropping it
(I didn't see one in the earlier comments).


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=350477.




More information about the Gstreamer-bugs mailing list