Finished part 1 of the Wayland McWayface tutorial of Drew DeVault - Issue with spi toolprovider interface and jextract

[Maurizio Cimadamore]

On 24/02/2019 18:31, Mark Hammons wrote:
> Regarding 1) I would try to fork the global scope to create pointers 
> for my callbacks. However, since the object that was taking the 
> callbacks was created by a wlr_backend_autocreate foreign function 
> call, I guess the scopes were incompatible and it would not accept the 
> pointers from the forked scope. You can give it a shot with my 
> repository. Just pass in scope.fork to anywhere I'm passing in a scope 
> and you should see the access violation messages. 

I see - it seems like:

1) you are obtaining a struct object from a native call

2) you are trying to set a callback on the struct object obtained in (1)

3) you are getting an exception

I think this is overall correct - if you think about it, there's no way 
for the API to know what is the lifecycle of the struct you are getting 
back from the native call. It could be something generated on the fly - 
or the library could just be returning a global, which will be alive for 
the entire duration of the library.

So, in these cases, we must assume the worst case scenario - that is, 
that the lifecycle of the struct obtained at (1) is essentially the 
lifecycle of the library itself. So, if you try to write something with 
a smaller lifecycle - the API prevents you from doing that, and in 
general for a good reason: if the native library was caching the struct 
somewhere, you can see where things could go wrong: you could set your 
callback, then your callback scope would go away and the library struct 
will now be polluted with a bad pointer.

I think forking/merging scope makes sense to keep your pointer 
hierarchies in check esp. if you are only interested in off-heap access 
only. When you start adding native calls into the mix, there's not a lot 
you can infer in terms of lifecycle, so, yes, I'd expect that in many 
cases you'll just use either the global or the library scope.

Maurizio