Re: Implicit casting issues when binding to C++
- From: Mike Pall <mike-1207@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sat, 7 Jul 2012 00:09:54 +0200
Janis Britals wrote:
> I compiled this hack and it seems to be working pretty well, except that
> sometimes I get strange assertion errors from trace recorder. Now it could
> be unrelated, but I'm pretty sure that it's caused by my hack, as I have
> only a vague idea about the whole JIT compiler thing and I think the extra
> manipulations on the Lua stack inside the conversion function probably
> throws the recorder off track.
The one thing that certainly kills it, is unexpectedly calling a
Lua function from within a type conversion. Use hook_vmevent(),
lua_pcall(), hook_restore() to prevent that. But then ... I'm not
even sure it's safe to call back into the VM in every context that
does a type conversion ... would have to check every case.
Oh, and ... the trace recorder needs it's own variation of the
type conversion functions (see crec_{tv|ct}* in lj_crecord.c).
They operate on the IR, not on TValues. You'll need to apply
similar changes there, or the JIT compiler won't work.
An interim solution would be to use trace_abort() whenever you do
a special conversion in the interpreter. Yep, this means those
calls to Qt would never get compiled. Probably good enough for
testing, though.
> In any case I did this hack only in order to achieve the proof of concept:
> that it is possible to bind to a sophisticated C++ library (Qt) via FFI
> keeping 100% of the functionality and ease of use.
Indeed, that's impressive -- congrats!
> Mike, can you, please, look at my hack (I've attached it to this message. It
> is enabled by #defining LJ_LPP) and give your opinion on the feasibility of
> such an extension to LuaJIT FFI?
Well, it won't make it into the source right now (too big of a
change before the feature freeze in LuaJIT 2.0) and not in this
state (not general enough).
However, I might be tempted to include a general, lightweight
mechanism to override or augment C type conversions. But without
dragging in half of the C++ implicit type conversion logic into
the FFI core. I'll need to think about it -- no promises.
> I understand your reticence regarding covering C++ [...]
Err, I'm not against covering C++. Actually it's mentioned in the
LuaJIT Roadmap in the list of potential features for LuaJIT 2.1.
--Mike
Other related posts:
