progress_callback arguments for *_async() functions have incorrect scope annoations.

[jhenstridge]

This isn't a problem I'm blocked on or anything: just a bug I noticed when reading through the code.

All the async functions declare their progress callback as:

 * @progress_callback: (allow-none) (scope call): function to callback with progress.

This tells a language binding that the callback will not be called after the return of the function call, so it is safe to free any ffi closures at that point. That's clearly incorrect here, as we'd expect to see the progress callback called multiple times after the function returns, right up until the async ready callback fires.

Neither of the other two scope types look to be appropriate:

• scope async callbacks may only be called once, with the language binding being free to clean up after that call.
• scope notified is the best fit (allows multiple calls after return from the function), but we don't provide a GDestroyNotify for the progress callback that it requires.

So it's not clear this can be solved purely by updating the annotations.

The synchronous functions look like they should be okay with scope call though: the progress callback will never be called again after those functions return.

[sergio-costas]

I presume that this would require a change in the API to include the GDestroyNotify parameter, isn't it?

[robert-ancell]

Yeah, for bindings to correctly handle this we'd have add an additional parameter, possibly by making new _full() functions. I don't know of any bindings in use currently though.