On Wed, Nov 21, 2018 at 10:22:38AM -0500, Nathan Froyd wrote:
> On Wed, Nov 21, 2018 at 4:45 AM David Teller <dtel...@mozilla.com> wrote:
> > What is our policy on using Unix signals on Firefox? I am currently
> > reviewing a patch by external contributors that involves inotify's
> > signal API, and I assume it's a bad idea, but I'd like to ask around
> > first before sending them back to the drawing board.
> I don't think we have a policy, per se; certainly we already have uses
> of signals in the JS engine's wasm implementation and the Gecko
> profiler.  But in those cases, signals are basically the only way to
> do what we want.  If there were alternative ways to accomplish those
> tasks besides signals, I think we would have avoided signals.
> inotify looks like it has a file descriptor-based interface which
> seems perfectly usable.  Not being familiar with inotify beyond
> reading http://man7.org/linux/man-pages/man7/inotify.7.html, is there
> a reason to prefer the signal interface versus the file descriptor
> interface?  We use the standard gio/gtk event loop, so hooking up the
> returned file descriptor from inotify_init should not be onerous.
> widget/gtk/nsAppShell.cpp even contains some code to crib from:
> https://searchfox.org/mozilla-central/source/widget/gtk/nsAppShell.cpp#275-281

I'd go one step further. We use Gio from libglib, is there a reason not
to use the GFileMonitor API, which wraps inotify?


dev-platform mailing list

Reply via email to