[RFC] removing library NCI signatures from core
plobsing at gmail.com
Wed Feb 17 16:22:59 UTC 2010
On Wed, Feb 17, 2010 at 11:06 AM, Andrew Whitworth
<wknight8111 at gmail.com> wrote:
> Now that's quite an interesting idea, but limiting. We need some kind
> of way to construct a call frame in order to provide a thin wrapper
> around an external library. If we create a more "thick" wrapper
> instead, such as a PMC class to wrap the interface, or a set of ops,
> we can do what you suggest. I don't like the idea of restricting what
> kinds of add-ons we can support, however. Some libraries don't lend
> themselves to being wrapped by a PMC or even a set of PMCs.
As an aside, methods on C-based PMCs use NCI thunks, so unless you can
shoehorn an API into vtables, you're no further ahead by trying to use
PMCs in the current system.
> As a middle-ground first step, howabout we break the non-necessary NCI
> signatures into a dynlib in the repo. That way we still have them in
> the repo if needed in the interim, we have a way to run tests on the
> mechanism locally, and we prepare for the larger refactors that Peter
> is suggesting.
Seems like a good idea to me. I would be willing to do the (small
amount) of work to make that happen.
> That's what we all want, but we cannot do that now. What we do now is
> really the worst possible solution, and making loadable libraries of
> NCI thunks is a huge improvement over that. In reality, we're probably
> not going to have proper dynamic native calls without one of two
> things: an existing dynamic interface (using libffi or libjit) or
As I understand it, Lorito is supposed to be small. A decent FFI will
need to implement at least a large chunk of the types your C compiler
works with. Because of the increase in scope (and associated
complexity) this causes, I'm not sure that we'd want to push native
interfacing into Lorito. Maybe I'm mistaken, please enlighten me if I
am (the vision for Lorito has always been a little hazy for me).
More information about the parrot-dev