[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Proposal: KSharedFile
From:       Holger Freyther <freyther () gmx ! net>
Date:       2001-12-07 13:42:07
[Download RAW message or body]

Am Freitag, 7. Dezember 2001 14:30 schrieb Cornelius Schumacher:
> On Friday 07 December 2001 07:11, Holger Freyther wrote:
> > Am Donnerstag, 6. Dezember 2001 21:09 schrieb Cornelius Schumacher:
> > > To solve this problem I would like to porpose a new class KSharedFile,
> > > which is used to access the file on both sides. KPilot would use the
> > > class and KOrganizer would also use the class. This class has to make
> > > sure that no two applications are writing to the file at the same time
> > > and that all applications having opened the file get notified, when the
> > > file is changed.
> >
> > qt tries to solve this problem different. For the QPE they developed
> > qcop. If the pda want's to think it sends a signal called flush() and if
> > syncing it's done it sends a reload(). This way it's much better.
> > KSharedFile will not easy to be made. There has to be a lot of locking.
> > Ok KDE3 will use the threaded version of qt3 and will get the mutexes for
> > free.
>
> You presume that it is clear, who has to be notified. 
no 
> It is simple, if only
> two apps can be participants in a syncing process, but in our case this is
> not the case, we can have several different apps operating on the same file
> at the same time. (see also my response to Adriaans mail for some more
> details about this scenario).
>
> The implementation of KSharedFile is not difficult. You write a lock file,
> if an application requests write access to the file, which prevents all
> other apps of getting write access. After writing, the lock file is deleted
> and other apps are free to require write access. For the notification, when
> the file is changed you setup a QTimer, which periodically checks, if the
> file has changed on disk. If it has the notification is sent.
There's a problem. Is KShareFile running only once ( like KTrader::self()-> ) 
or is there a instance in every program? 
I guess it willl run uniquely ( I hope so ) ok it does(n't) matter much.
My mind just came up with two cases for a case with the lock files.
Case1:
We've to processes a and b. Now both want to write to the file. a checks 
(with KSharedFile )if there's an myfile.shared.lock and it finds out there's 
none. No the scheduler interupts a and starts b it checks if it's free and 
yes it is and then it creates the file and thinks it can sync safely. Now a 
runs and tries set's the lock to this file and starts writing too. The result 
is not predictable.
We need a global unique KShareFile-Server with Mutexes or other stuff. Then 
every app connects to the (dcop)-signals of the Server. If there's a sync() 
signal all apps sync and on reload() they know it's safe to reload.
>
> > This is where a SyncServer :) comes in handy.
>
> You could also let a server process handle the locking (e.g. a special kded
> module). But the advantage of using a lock file is that it also works
> across different machines, e.g. over NFS.
NFS is not really true. I remember seeing problems with star office over nfs 
beacause there was in userspace or was it knfsd no implementation for locking.

regards Holger
PS: My proposol is to write a Server Either a kuniqueapp and a lib for 
convience (like hiding we're using dcop) or go directly to my SyncServer 
approach.
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim

[prev in list] [next in list] [prev in thread] [next in thread]