Re: FFI and Objective C

[Eric Wing <ewmailing@...>]

On 11/23/16, Daurnimator <quae@daurnimator.com> wrote:
> On 24 November 2016 at 01:08, Eric Wing <ewmailing@gmail.com> wrote:
>> 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 mentioned it to you at the workshop, did you get to look at
> http://daurnimator.com/post/147024385399/using-your-own-main-loop-on-osx
>
>

Thank you for the link. As somebody who has had to fight frameworks
taking over event loops, that is interesting information. (Though
unfortunately, I think the Mac App Store rejects on private API use.)


But for LuaCocoa, there is no event loop. LuaCocoa tries very hard to
not force decisions on how you write your app, allowing it to be
integrated in all sort of environments. Ultimately, it is your app
that creates the run-loop.


The way blocks work with LuaCocoa is that when you create a Lua
function to be used as a block, LuaCocoa dynamically creates a generic
wrapper/proxy block (ffi closure). In this wrapper block, the Lua
function is stored. This wrapper block is what gets passed to the
native API accepting the block parameter.

So when the system calls-back this block, it is indeed this wrapper
block. My wrapper block has code which in turn calls the stored Lua
function.

One extra thing my code tries to do before it invokes the Lua
function, is track which thread we’re being invoked on on and compare
to the originating thread. If they are different, there is some awful
things I do to try to perform the call on the originating thread. For
typical cases, this seems to work, but for the concurrent stuff, I can
seem to run into deadlocks.


I infer that you prompting me about controlling the event loop may
allow me to pre-sort/schedule how to deal with blocks before the
callback is invoked which maybe could avoid the need to deal with the
problem after the callback has been invoked. I'm not particularly keen
on LuaCocoa taking control of the event-loop, but it is an interesting
idea in general.


Thanks,
Eric