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

classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
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: [hidden email]
          Reporter: [hidden email]
          Keywords: patch
             Flags: maintainer-feedback?([hidden email])
          Assignee: [hidden email]

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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
[hidden email] has reassigned Bugzilla Automation <[hidden email]>'s
request for maintainer-feedback to [hidden email]:
Bug 214338: devel/glib20: patch: new kqueue() backend for file monitoring
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338



--- Description ---
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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

Vladimir Kondratyev <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Vladimir Kondratyev <[hidden email]> ---
(In reply to rozhuk.im from comment #0)
> - no additional threads created

Just wondering. Is it safe to call readdir() from glib worker thread context?
Are there any chances that glib-based application would just freeze if
readdir() would take tooooo looong time to complete?

I don`t know much about glib internals, that is why I am asking

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #2 from [hidden email] ---
I use this patch mo than 10 days and all OK - no freezes, no high CPU usage. I
think kernel cache files/dirs info for most cases.
I don`t know much about glib internals too. :)
Thats why code have only tinny API shim from my code that can be used in any
application on BSD to glib filemon plugin API.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #3 from Vladimir Kondratyev <[hidden email]> ---
(In reply to rozhuk.im from comment #2)
> I use this patch mo than 10 days and all OK - no freezes, no high CPU usage.
> I think kernel cache files/dirs info for most cases.

No doubt, it should work nice in most desktop usages. But there are some worst
-case scenarios like:
1. Working over slow and unreliable media like mounted network shares
especially when public networks are used
2. Working with userspace filesystems under heavy CPU load and memory pressure
3. Working with large directories on medium-speed media like USB1/2-dongles

I have seen readdir()s lasting for more than minute in real life and it is
undesirable to see application stopped that time. I think you can avoid this
with using of some async io libraries like libeio but that just moves thread
creation from gio to external library.

I see more issues in your backend but this one is most important IMO

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

Ting-Wei Lan <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #4 from Ting-Wei Lan <[hidden email]> ---
(In reply to rozhuk.im from comment #0)
I opened an upstream bug report for kqueue backend reworking 2 years ago:
https://bugzilla.gnome.org/show_bug.cgi?id=739424

You can regenerate your patch in 'git format-patch' format and upload it there
to get feedback from upstream developers. kqueue backend is used by many
operating systems, so your code will be tested on other operating system like
OpenBSD before it can be accepted by upstream.

From the discussion on IRC we had last year, the reason to have a polling
fallback is that kqueue requires a file descriptor to the directory to be
monitored, but having an open file descriptor blocks unmount. Linux inotify
doesn't have this problem because inotify uses a file path instead of a file
descriptor, and Apple Mac allows getting a file descriptor for use in kqueue
without blocking unmount by using O_EVTONLY.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

Antoine Jacoutot <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #5 from Antoine Jacoutot <[hidden email]> ---
(In reply to Ting-Wei Lan from comment #4)

I can give it a try on OpenBSD this week-end if you want.
AFAIK the polling code is also used when running out of file descriptors (which
is limited by kern.maxfiles sysctl in and openfiles in login.conf).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #6 from Ting-Wei Lan <[hidden email]> ---
(In reply to Antoine Jacoutot from comment #5)
I didn't mean to ask for testing now. I think we can test it after it has been
reviewed by at least one person.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #7 from [hidden email] ---
(In reply to Vladimir Kondratyev from comment #3)

All your "worst cases" match better then high CPU usage after short time of use
original backend.

1, 3 No events received from remote systems if other host change files.
If files changed by system with my code - all changes cached by kernel.
I see some freezes on dir open, where thunar add other dir to monitoring and
they open() for read and they filetime updates.

2. In this case original code will do same, no difference.

In some previous version I use additional thread for receive and process kqueue
events, but for now I se no difference.
May be glib create its own thread to handle read events from kqueue, I do not
investigate this.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #8 from Vladimir Kondratyev <[hidden email]> ---
(In reply to Ting-Wei Lan from comment #6)
> I think we can test it after it has been reviewed by at least one person.

For now I see 3 major issues with this patch.

1. Possible glib worker thread blocking (discutable, I like the idea to move
event processing from dedicated thread to glib worker)
2. Multiple hardlinked files in single directory are not handled properly -
rename tracking code just search for first file with the same inode number not
taking in account if it still persists in directory or not
3. No watching for modifying/attribute changing of files inside watched
directory.

I think, implementing 2 & 3 will lead to reinventing libinotify which old
version is a base of current kqueue backend

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #9 from [hidden email] ---
(In reply to Ting-Wei Lan from comment #4)
unmount block if one or more filemanagers watch for dir, user can close
filemanager and retry unmount.
I use umount -f, and make this fix:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214336

O_EVTONLY may be some one add to FreeBSD...

I will post my patch to upstream later.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #10 from [hidden email] ---
(In reply to Vladimir Kondratyev from comment #8)

1. You can add sleep(10000) over kevent() to test freezes.

2. If file deleted it will reported.

3. Im not sure about it. Code compare current files/subdirs metadata in dir
with previous and report if changed. But if no event from kqueue() received for
dir then no compare/report for files/subdirs.

I can add polling by timer to handle this case and network mounts but I think
that it bad idea.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #11 from Vladimir Kondratyev <[hidden email]> ---
(In reply to rozhuk.im from comment #10)
> 2. If file deleted it will reported.
It seems that I did not explain well what i meant.

We are watching for directory with hardlinked childs "1" and "2". They are
sharing same inode number as it is one file with 2 links to parent dir.

Than we rename "1" to "3" triggering NOTE_WRITE for parent directory filedesc

gio handler for NOTE_WRITE calls your code and at some point of time readdir()
loop reads entry for file "3" and find it as "new file".

Next step it tries to find out if this file has been renamed and after some
looping over previous directory content with 50% probability it stops at file
"2" with the same inode number and decides that "2" is the filename before
rename
But that is wrong as you would send 3 events in that case: '"1" is deleted',
'"2" is renamed to "3"' and '"2" is created'.

> 3. Im not sure about it. Code compare current files/subdirs metadata in dir with previous and report if changed.
> But if no event from kqueue() received for dir then no compare/report for files/subdirs.

IIRC, if directory is watched, file monitor should report child files attribute
changes and modifications. In kqueue() case it means that you should open()
every child file and watch for NOTE_ATTRIB, NOTE_WRITE and NOTE_CLOSE_WRITE
(and maybe NOTE_DELETE as it mapped to attribute changes sometimes) events.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #12 from Vladimir Kondratyev <[hidden email]> ---
(In reply to Vladimir Kondratyev from comment #11)
> But that is wrong as you would send 3 events in that case:
> '"1" is deleted', '"2" is renamed to "3"' and '"2" is created'.

Current gio-kqueue backend uses 4-pass algorithm to solve issues like this one
and implement correct event-ordering

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

--- Comment #13 from [hidden email] ---
Is there some real issues with my current implementation?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #176801|0                           |1
        is obsolete|                            |

--- Comment #14 from [hidden email] ---
Created attachment 178938
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178938&action=edit
kqueue() file monitoring backend: async add/delete monitor

Now add/remove file/dir monitoring is async.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://bugzilla.gnome.org/
                   |                            |show_bug.cgi?id=779777

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #178938|0                           |1
        is obsolete|                            |

--- Comment #15 from [hidden email] ---
Created attachment 181557
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181557&action=edit
readdir_r() -> getdirentries()

After some system/ports updates during this months app start crash on standard
open dialog: (geany in this trace)
I fail to reproduce this in demo app, so I decide replace  readdir_r() to
getdirentries() and this helps.


#0  0x0000000803e856ea in thr_kill () from /lib/libc.so.7
#1  0x0000000803e856b4 in raise () from /lib/libc.so.7
#2  0x0000000803e85629 in abort () from /lib/libc.so.7
#3  0x000000080206641a in pthread_attr_getaffinity_np () from /lib/libthr.so.3
#4  0x00000008020601c1 in pthread_mutex_destroy () from /lib/libthr.so.3
#5  0x00000008020606bd in pthread_mutex_destroy () from /lib/libthr.so.3
#6  0x000000080205f8c9 in pthread_mutex_lock () from /lib/libthr.so.3
#7  0x0000000803ef89d2 in readdir_r () from /lib/libc.so.7
#8  0x0000000802f9666a in kqueue_file_mon_data_init (fmd=0x80f99b700) at
kqueue_fnm.c:262
#9  0x0000000802f96020 in kqueue_fnm_delay_call_process (kfnm=0x80f6f14e0,
forced_msg_cb=0) at kqueue_fnm.c:498
#10 0x0000000802f969fe in kqueue_fnm_proccess_events (kfnm=0x80f6f14e0,
cb_func=0x802f95e00 <kqueue_event_handler>) at kqueue_fnm.c:621
#11 0x0000000802f95de4 in g_kqueue_file_monitor_callback (fd=14,
condition=G_IO_IN, user_data=0x0) at gkqueuefilemonitor.c:92
#12 0x000000080393893a in g_unix_fd_source_dispatch (source=0x80cb6faf0,
callback=0x802f95db0 <g_kqueue_file_monitor_callback>, user_data=0x0) at
glib-unix.c:308
#13 0x00000008038d2be3 in g_main_dispatch (context=0x80ae41700) at gmain.c:3203
#14 0x00000008038d2a30 in g_main_context_dispatch (context=0x80ae41700) at
gmain.c:3856
#15 0x00000008038d2f7e in g_main_context_iterate (context=0x80ae41700, block=1,
dispatch=1, self=0x80b08b280) at gmain.c:3929
#16 0x00000008038d2ff3 in g_main_context_iteration (context=0x80ae41700,
may_block=1) at gmain.c:3990
#17 0x00000008038d498d in glib_worker_main (data=0x0) at gmain.c:5783
#18 0x000000080390ae9d in g_thread_proxy (data=0x80b08b280) at gthread.c:784
#19 0x0000000802058bd5 in pthread_create () from /lib/libthr.so.3
#20 0x0000000000000000 in ?? ()

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #181557|0                           |1
        is obsolete|                            |

--- Comment #16 from [hidden email] ---
Created attachment 181816
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=181816&action=edit
fix mem corruption

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

bugzilla-noreply
In reply to this post by bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #181816|0                           |1
        is obsolete|                            |

--- Comment #17 from [hidden email] ---
Created attachment 182423
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182423&action=edit
update to build with last svn version

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gnome
To unsubscribe, send any mail to "[hidden email]"
12345