From kde-devel Sat Nov 30 02:11:01 2002 From: Josef Weidendorfer Date: Sat, 30 Nov 2002 02:11:01 +0000 To: kde-devel Subject: Re: FAM and 3.1rc3 X-MARC-Message: https://marc.info/?l=kde-devel&m=103862491526015 On Saturday 30 November 2002 01:29, Manuel Amador wrote: > > Hi, > > > > the reasoning behind FAM is to keep CPU resources low for application= s > > that want reaction on file changes. > > The need for this is *not* given when only one application is looking= for > > changes in a local directory: it can do polling at reasonable interva= ls. > > This is the case with Konqui when you disable FAM and dnotify. As you > > say, you get perfect and reasonable behaviour. > > Yes but FAM should also behave sanely, if it's enabled. I really don't > care about the option to disable it, 100% CPU usage with DD is a bug, > and should be treated like that. Are you caring for all FAM users in general or for yourself? This is NOT a FAM bug (again see other mail). It's your distributions fau= lt to=20 patch the original FAM package to support dnotify. So general, this bug=20 doesn't exist. If your distribution forces you to use all eye-candy available in KDE by=20 configuring this as default, even when installed on a 5 year old machine,= is=20 KDE the one to blame? >... > > * the directory to watch for changes is remotely mounted. As STATs ov= er > > NFS are slow, > > why? Any network access can't be faster than a ping. And it influences network= =20 traffic, slowing down access times for all users on that network, plus pu= ts=20 load on the file server. As said, the STAT usage needs regular polling (e.g. every few seconds). T= hus,=20 leading to a constant increase of net traffic. FAM on the contrary only s= ends=20 something over the net when there is a file change. > > Drawbacks of DNOTIFY: > > - DNOTIFY forces FAM to open the directory which contains files to be > > watched. This means problems with unmounting devices. Simple advice: = Kill > > the FAM daemon before unmounting ;-) > > OH! That's the sucker! This pinpoints to errors in the conceptual > implementation. Yes. DNOTIFY is conceptually not usable for watching files that can be=20 unmounted ;-) > > - DNOTIFY has *no* event delaying. For every write syscall to a watch= ed > > file, DNOTIFY produces immediatly a signal (for FAM). > > FAM should keep track of signals and throttle them. I know this is a > dnotify bug, but barring swift corrections to the kernel code, FAM > should make do with what it has. The user application has no possibility to limit/throttle realtime signal= s=20 delivered to it once it has requested them. It simply has to avoid realti= me=20 signals at all if they could come in at a high rate. Yes. This is a bug in the DNOTIFY support in FAM. Aside from that, it doesn't need to notify for every signal it gets. A bu= g,=20 too. > > My advice: > > - Use FAM, but recompile *without* dnotify support. > > - Blame your distribution for using the problematic dnotify support f= or > > FAM. - Mail the LINUX kernel list for adding a "delay" option for dno= tify > > (e.g. signal generation is delayed by 200 ms after the event happend, > > merging events) and for dnotify not being in the way for unmounting (= e.g. > > by using a single /dev/dnotify for notifications or forcing closing o= f > > dnotify file descriptors on unmounting). > > isn't it easier for FAM to detect multiple close events and merge them > into one single application event to be sent? There might be a reason > why you want real time notification in apps using dnotify... Yes. But the delivering of the signal itself is already unneeded load. Josef >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<