inotify ffi

inotify ffi

[Chaos Eternal]

i wrote a FFI to inotify system call.

https://github.com/ChaosEternal/guile-inotify2

procedures:
* inotify-init
* inotify-init1
* inotify-add-watch
* inotify-rm-watch
* inotify-read-port

the errno handle is unreliable, use with caution.

License: LGPL v3

Re: inotify ffi

[Chaos Eternal]

and it is not very portable.


On Wed, Nov 12, 2014 at 1:55 AM, Chaos Eternal <chaoseternal@shlug.org> wrote:
> i wrote a FFI to inotify system call.
>
> https://github.com/ChaosEternal/guile-inotify2
>
> procedures:
> * inotify-init
> * inotify-init1
> * inotify-add-watch
> * inotify-rm-watch
> * inotify-read-port
>
> the errno handle is unreliable, use with caution.
>
> License: LGPL v3

Re: inotify ffi

[Mark H Weaver]

Chaos Eternal <chaoseternal@shlug.org> writes:
> i wrote a FFI to inotify system call.
>
> https://github.com/ChaosEternal/guile-inotify2
>
> procedures:
> * inotify-init
> * inotify-init1
> * inotify-add-watch
> * inotify-rm-watch
> * inotify-read-port
>
> the errno handle is unreliable, use with caution.
>
> License: LGPL v3

and later, he wrote:
> and it is not very portable.

Thanks for working on this, but as you pointed out, the method you use
to check 'errno' is extremely unportable and also quite fragile.  It
makes assumptions about internal details of the C library and Guile, and
is likely to break in future versions of glibc and/or Guile.

It might not even work properly with current versions.  There are many
things that could happen between the call to the C function and checking
'errno' that might disturb the value of 'errno'.

Unfortunately, there's currently no proper way to check 'errno' using
the Dynamic FFI.  For now, the only proper solution is to write a C
extension as described in:

  http://www.gnu.org/software/guile/manual/html_node/C-Extensions.html

Your C wrapper should call the relevant C function and then immediately
read the value of 'errno' if the return value indicates an error.  You
should not make any calls to libguile before reading 'errno'.

Hopefully, Guile 2.0.12 will include a way to check 'errno' after calls
to the Dynamic FFI.  Most likely, this will involve adding a keyword
argument to 'pointer->procedure' that causes the generated wrapper to
check 'errno' immediately after the C function returns.  The ticket for
this issue is here: http://bugs.gnu.org/18592

      Regards,
        Mark

Re: inotify ffi

[Eli Zaretskii]

> Date: Wed, 12 Nov 2014 01:59:13 +0800
> From: Chaos Eternal <chaoseternal@shlug.org>
> 
> and it is not very portable.
> 
> 
> On Wed, Nov 12, 2014 at 1:55 AM, Chaos Eternal <chaoseternal@shlug.org> wrote:
> > i wrote a FFI to inotify system call.
> >
> > https://github.com/ChaosEternal/guile-inotify2
> >
> > procedures:
> > * inotify-init
> > * inotify-init1
> > * inotify-add-watch
> > * inotify-rm-watch
> > * inotify-read-port
> >
> > the errno handle is unreliable, use with caution.
> >
> > License: LGPL v3

Why not use the glib file monitoring instead?  It is much more
portable, and has an inotify back-end AFAIK.

Re: inotify ffi

[David Thompson]

Eli Zaretskii <eliz@gnu.org> writes:

> Why not use the glib file monitoring instead?  It is much more
> portable, and has an inotify back-end AFAIK.

If you're only after inotify, glib seems like a heavy dependency.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: inotify ffi

[Eli Zaretskii]

> From: David Thompson <dthompson2@worcester.edu>
> Cc: guile-devel@gnu.org
> Date: Tue, 11 Nov 2014 15:05:05 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why not use the glib file monitoring instead?  It is much more
> > portable, and has an inotify back-end AFAIK.
> 
> If you're only after inotify, glib seems like a heavy dependency.

But inotify is practically a single-OS solution.  How does it make
sense for Guile to support file notifications only on one platform?
That effectively limits packages that use Guile as an extension
language to that single platform.

Anyway, Guile already depends on quite a few external libraries, so
adding a few more doesn't sound a big deal to me, FWIW.

Re: inotify ffi

[David Thompson]

Eli Zaretskii <eliz@gnu.org> writes:

> But inotify is practically a single-OS solution.  How does it make
> sense for Guile to support file notifications only on one platform?
> That effectively limits packages that use Guile as an extension
> language to that single platform.

From what I could see, this is a third-party library, not one intended
for Guile core.  If such support were to be added to Guile core, I would
agree that it should be cross-platform.

I'm interested in file notifications for a project of mine, but I'm not
sure I would want to introduce glib as a dependency if I'm only using
that one feature.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate