lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <n...@verse.com>
Subject Re: [lucy-dev] OFFSET globals
Date Tue, 24 Apr 2012 05:20:51 GMT
On Mon, Apr 23, 2012 at 8:38 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
>> 1) This can and should be solved through DSO symbol versioning.
>
> Hmm, I'm not sure that the problem we're working on can actually be solved
> this way.  What we're tying to protect against is the possible *removal* of a
> symbol.  I don't see how you guard against that using DSO symbol versioning.

Then you are likely right!  I'm still doing background reading to
fully understand the problem.  Just made may way through the short and
quite readable paper by Wu (which I found easier to read as a PDF:
http://static.usenix.org/events/javavm02/yu/yu.pdf).  Also finding a
couple posts by Eli to be useful:
http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/

Also, I didn't mean that symbol versioning was all we needed -- rather
 I was thinking (and still think, but perhaps only due to ignorance)
that  we can leverage the runtime linker to solve most of this
problem.  We'd still need some way of updating the the appropriate
offsets, but my hope was that we could get the linker to do this for
us rather than needing to do our own second bootstrap pass.

>> 2) It's great to get things right so as to have a solid foundation, but
>> 3) We got along just fine for years without actually implementing this, thus
>> 4) We don't need to solve this right now, just future-proof ourselves.
>
> Well, the reason we're working on this now is that Nick wants to write
> compiled extensions, and we want to be able to update Lucy without breaking
> his compiled extensions.  We haven't needed this until now because we haven't
> supported compiled extensions, but that's changing!

A fine reason to finally do this right, and having him excited to
solve this is another.  But I haven't been sure whether it's Nick
demanding an upgrade proof ABI, or whether you feel it should be one.
I was wondering whether it would be better to have him continue
writing extensions and recompiling as necessary until the ABI settles
down, since the process of writing these extensions will probably
cause faster change than will be the usual case.

But as long as _both_ of you view this as a preliminary requirement,
it's a great thing to get out of the way.

---

Checking that my understanding the scope of the problem is correct:

1) We want to make it possible to add methods to core Lucy objects on
a library upgrade without requiring a recompile of extension classes
that inherit from these.

2) We don't want to allow "monkey-patching" of classes at runtime,
such that an extension can make changes to parent classes that
propagate back to the child classes.

3) We want to handle the case of a method that moves from a parent
class to a grandparent, and vice versa.   As long as it's in the chain
of ancestors, the exact location shouldn't matter.

4) In all other cases (removal or signature change of an inherited
method) we just want to detect the incompatibility at start time and
die with an appropriate error message rather than randomly crashing or
doing the wrong thing.

5) It's OK to start with a Linux-only solution, so long as there is a
pathway to a solution on Windows and OSX, and it's OK to to have a
solution that is efficient only on x64 as long as there is an x86
workaround. (?)

Are these correct?  Are the requirements I'm missing?

--nate

Mime
View raw message