Re: Lisp object that refers to a C struct

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Thu, 18 Oct 2012 18:09:46 -0400
> 
> > It doesn't.  I meant the need to manage the table itself, grow it when
> > needed, etc.
> 
> To me "table" doesn't imply "array".  It's just some kind of
> data-structure that keeps the elements at hand.  It can be a list, an
> array, a tree, a has-table, you name it.

If we use a Lisp data structure, then the same issue of putting a bare
pointer into that started this thread it pops up again, doesn't it?

Anyway, a Lisp data structure is what I have now.

> >> (BTW, is this table usable by Lisp, e.g. can they get the list of
> >> current file-watchers?).
> > Yes, it's an alist.  But it currently isn't exposed to Lisp, neither
> > as a variable nor via an API.  It could be, of course.  But since
> > Rüdiger didn't, and since we didn't discuss in detail how this feature
> > will be used from Lisp, I didn't want to introduce APIs whose
> > necessity is not clear.
> 
> Note that if we use integers instead of a new type, we can't free
> those structs when the Lisp code loses the last reference to the
> file-watcher.

The list is maintained by 2 primitives, which take care of that.  And
the list itself is statically protected from GC.  If some disaster
strikes and the list is somehow thrashed or released by some evil
magic, then all we have is a bunch of threads watching file-change
notifications that no one can hear, threads which can only be
stopped by shutting down Emacs.  Not too bad, considering the doomsday
scenario under which it can happen.

> > Call w32_valid_pointer_p, and in addition verify that the struct
> > pointed to by it has the correct magic signature.
> 
> Why is that needed?

To make sure we never dereference a pointer that doesn't point to the
watch object.  Since the remove-watch API accepts a Lisp integer, it
could be called with any arbitrary integer value.

IOW, I don't want to crash, even if somehow a bad pointer is found in
the alist described below.

> Can you give a precise description of your alist?

It's an alist of cons cells like this:

   (DESCRIPTOR . CALLBACK)

where DESCRIPTOR is a pointer to the C struct as a Lisp integer, and
CALLBACK is a function to call when the file notification event comes
in.  A single cons cell describes a single file-change notification
request; each such request allocates another C struct (and thus gets
another DESCRIPTOR) and starts another thread.

As I wrote, the reason for this design of the alist was to be 100%
compatible with what Rüdiger did.  Otherwise, I could keep CALLBACK in
the C struct as well, for example.