Re: FFI and Objective C

[Eric Wing <ewmailing@...>]

On 11/22/16, Chris Jones <cmsj@tenshu.net> wrote:
> Hey
>
> On 19 November 2016 at 05:22, Eric Wing <ewmailing@gmail.com> wrote:
>>
>> I've been interested in moving to Lua 5.3. So I'd love to incorporate
>> your changes. Lua 5.3 integers removes the need for the LNUM patch I
>> currently use.
>>
>
> I now have a fairly hacky conversion that appears to pass the TestApp, and
> AFAICS, runs all of the examples correctly, with the possible exception of
> the Action 4 button in BlocksExample (which just seems to hang after quite
> a few block invocations). I've not had a chance to dig into that yet.
>

Fantastic!

Action 4 is known to deadlock so don't worry about it. (There is a
comment in the Lua code about it.) Basically this is the Cocoa API
trying to concurrently operate on each element in the array. I tried
some tricks to try to deal with this, but they were unsuccessful. I'm
thinking this may only be solvable with a global interpretor lock, but
I really don't want to do that. I was holding out hope there may be
some other libdispatch trick. For now, these Cocoa APIs have a
parameter to say to not do things concurrently which avoids this
entire problem.


> I've tried to avoid keeping 5.1 API calls around via #defines where I
> could, but e.g. {get,set}fenv() are currently being handled with a mixture
> of #define and some subsequent boilerplate in the getfenv() case. This
> would be pretty easy to change

My only thinking here is it would be nice if we could make it easy for
somebody to switch back to 5.1. Though honestly, at this point in
time, I don't expect there to be many changes in LuaCocoa and I don't
really expect anybody new to ask for 5.1 at this point.


> There's also something weird going on with my whitespace, annoyingly!
>

I probably should just use clang format.

> Excluding the diff from replacing Lua 5.1 src with 5.3, the diffstat is
> pretty reasonable:  15 files changed, 218 insertions(+), 128 deletions(-)
>
> I've pushed up my changes to: https://bitbucket.org/cmsj/luacocoa - happy
> to get whatever feedback you have :)
>
>> I have an updated version of my Lua patch (now for 5.3) to make it use
>> Objective-C exception handling for pcall. Just to get things basically
>>
>
> I'm curious about this part. I didn't pay any attention to it for this
> first stage. What does it do?
>


My patch modifies Lua so it will use Objective-C's exception handling
mechanism instead of _setjmp/_longjmp for pcall.

This protects you in case something throws an exception on the system
when you are in a pcall. This could happen if either a user or system
library throws an exception. I’ve also seen it happen in cases where
there was an internal Apple bug in one of the system frameworks and it
threw an exception.

With setjmp/longjmp, Lua has no idea that an exception was thrown and
the execution jumped out of the Lua VM. This could lead to unexpected
behavior, memory leaks, and even crashes.

Switching to Objective-C's exception handling mechansism allows Lua to catch
all exceptions during a lua_pcall also gives the ability for Lua script writers
to trap/handle Obj-C exceptions from their own pcall's.


There are also two bonuses:

- On the “modern” Objective-C runtime, Obj-C and C++ exceptions are
unified, so this can be used for C++ exceptions too.

- The “modern” Obj-C runtime uses “zero-cost exceptions”, which means
the @try setup is essentially free (performance benefit for pcall)


So generally everybody should be using this pcall/Obj-C exception
patch on all Apple platforms (macOS, iOS, tvOS, watchOS). It is the
most correct code for Apple platforms, it has a bunch of benefits, and
no drawbacks (except that it cannot be used for Mac OS X 10.4 or
below, though it is now extremely hard to even find Macs that can run
that low since new Macs cannot run anything lower than they ship
with.).



I've pushed up a new working repo with your changes and my pcall/Obj-C
patch applied here:
https://bitbucket.org/ewing/luacocoa53

It's not really tested...probably should add some tests to LuaCocoa for this.


I also made a few fixes to the Xcode project and moved the defines to
the preprocessor section.

One additional thought, I would like to try to stay as close to the
Lua 5.3 default definitions as possible (just to simplify people
having to remember what definitions were used). I don't think
LUA_COMPAT_MODULE is a default, so it might be nice to work towards
removing this.

Thanks,
Eric