Re: Get libffi closures to cope with SELinux execmem/execmod

[Andrew Haley <aph at redhat dot com>]

Alexandre Oliva writes:
 > On Jan 22, 2007, Alexandre Oliva <aoliva@redhat.com> wrote:
 > 
 > > Now, if I'm reading you correctly, it's not the object itself that
 > > determines whether its finalizer can run while there are other
 > > pointers to it, but rather the object that points to it.  Is this
 > > correct?
 > 
 > It was, so I added an option to get the other behavior, that appears
 > to be generally desirable for Java system-level resource disposal,
 > through objects whose finalizers should only run when the
 > corresponding objects are unreachable even from other finalizable
 > objects.  It was quite easy to add, after I figured out how it worked.
 > 
 > > As it turned out, this wasn't enough, but adding a second layer of
 > > indirection to the closure list, such that both levels of indirection
 > > involve finalizers registered with the traditional (!= Java)
 > > semantics, it should work, right?
 > 
 > No.  Especially if one allocates the doubly-indirect pointer as not
 > containing pointers.  *blush*  :-)
 > 
 > Fixing that enabled things to work until I added finalizers that would
 > resurrect objects, perhaps even multiple times (consider a finalizer
 > that optionally creates another instance of the same class, bringing
 > back to life the class and the class loader).
 > 
 > At that point, after scratching my head for a while trying to figure
 > out a way to implement the needed semantics with the existing
 > primitives, I concluded it couldn't be done, and so I came up with new
 > finalizer semantics option described above.
 > 
 > Is this ok to install?  Tested on x86_64-linux-gnu.

Mmm, this looks good.  

OK, Hans?

Paging Anthony Green ... any comments?

Andrew.