[Bug 214338] devel/glib20: patch: new kqueue() backend for file monitoring

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Nov 8 21:15:41 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

            Bug ID: 214338
           Summary: devel/glib20: patch: new kqueue() backend for file
                    monitoring
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: gnome at FreeBSD.org
          Reporter: rozhuk.im at gmail.com
          Keywords: patch
             Flags: maintainer-feedback?(gnome at FreeBSD.org)
          Assignee: gnome at FreeBSD.org

Created attachment 176801
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=176801&action=edit
kqueue() file monitoring backend

Original kqueue() file monitor uses polling to monitor files in /mnt and all
path that can be unmounted.
On my system thunar eat 100% CPU after short time browsing sshfs, smbfs shares.
But on Apple MAC (where defined O_EVTONLY) kqueue() always used.

My code based on FAM backend (
https://github.com/GNOME/glib/blob/master/gio/fam/gfamfilemonitor.c ):
- no additional threads created
- no hash tables used
- lock() only in few placed: on init and on kqueue() events process (may be
this can be removed, I m not sure how glib process read events)
- small and simple code: ~500 lines, that easy to understand and debug without
glib

If you have some sshfs/smb mount point and some one (not from your host) change
files there - no notifications will be received: kqueue() does not handle it.
Original code use polling.
Im not sure does inotify, fam, kqueue() on apple mac and others handle it.

I can add polling by timer but it may take many CPU resources, like glib based
polling in original kqueue backend.


I need your opinions and feedback.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ports-bugs mailing list