Re: [Tracker] What invokes writeback actions and what process carries out these actions

[Philip Van Hoof <philip codeminded be>]

On Sun, 2011-08-21 at 14:44 +0300, Adrien Bustany wrote:
> # Re-adding the list in CC
> Le Sun, 21 Aug 2011 23:40:28 +1200,
> James Hurford <terrasea gmail com> a Ãcrit :
>
> > On 21 August 2011 23:20, Adrien Bustany <abustany gnome org> wrote:
> > > Actually, updates from miner would also trigger writeback, but the
> > > miner calls a method called IgnoreNextUpdate (iirc) to avoid a
> > > mining/writeback loop. That mechanism will probably be replaced in
> > > the future though, since it's racy.
> > >
> > > Cheers
> > >
> > > Adrien
> >
> > Thanks Adrien
> >
> > It's difficult to think of the miner invoking the writebacks, due to
> > them being the source of the information, but I can see there maybe
> > occasions when this behaviour maybe desired.  That does seem like a
> > source of future bugs though.
>
> You're perfectly right, it's not desired.
> I actually said rubbish in my last mail: the IgnoreNextUpdate call is
> on the miner, not the store (sorry for the confusion). So the process
> is:
> 1. Process X write a change to tracker store affecting a writeback
>    property for file F

That's the only correct point :)

> 2. The store calls IgnoreNextUpdate(F) on the FS miner

No, it used to be tracker-writeback who called IgnoreNextUpdate. But
this ain't true anymore. Not in master nor in 0.10

> 3. The store calls the writeback process to write the actual changes to
>    the file

Also not true. Never has been ;). tracker-writeback was a standalone
process that listened for the Writeback signal coming from the store.

Nowadays the FS miner calls a D-Bus message on tracker-writeback (in
exactly the same way it does so on tracker-extract). The
tracker-writeback process doesn't itself listen for Writeback signals
coming from the store anymore. The FS miner does this.

> 4. The miner sees the update, but also knows that it should ignore it

The miner nowadays receives the update, and ignores having to mine the
file being written back because it itself wraps the entire DBus call to
tracker-writeback (start to end), so it knows when the writeback is
finished and thus when to continue listening for real changes.

Regards,

Philip


-- 


Philip Van Hoof
freelance software developer
Codeminded BVBA - http://codeminded.be