Release GCHandle in FSEventStreamContext release callback

[jkotas]

The callbacks are sometimes delivered even after the FSEventStream is disposed

Fixes #30056

[ghost]

Tagging subscribers to this area: @carlossanlop
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The callbacks are sometimes delivered even after the FSEventStream is disposed

Fixes #30056

Author:	jkotas
Assignees:	-
Labels:	area-System.IO
Milestone:	-

[jkotas]

Match the names in Apple SDK

[adamsitnik]

LGTM, thank you @jkotas

Are there any other places where we are passing pointers to functions to native methods that we should revisit and ensure we do it always right as you just did here?

Not related to this particular PR, but do we have any guidance on when we should be trying to implement new features that call native methods using 100% managed code (and function pointers) vs extending the native PAL layer? An example: we will be adding symbolic links support very soon. Let's say there is an abc method that works on every Unix system (no need for #if defines). Should we use function pointers? Or add another method to pal_io.c?

[jkotas]

Are there any other places where we are passing pointers to functions to native methods that we should revisit and ensure we do it always right as you just did here?

The OS API in this case has a complex lifetime semantics that are not very well documented. We do not call Apple API like this anywhere else.

Also, I am not 100% sure whether this will actually fix the reliability issues that we facing with this component. We will only know after it runs for some time.

do we have any guidance on when we should be trying to implement new features that call native methods using 100% managed code (and function pointers) vs extending the native PAL layer?

The guidance is written down here: https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/interop-guidelines.md#unix-shims

Or add another method to pal_io.c?

The symlinks support should add more methods to pal_io.c per the above guidelines.

Should we use function pointers?

For simple calls into unmanaged code, we should be using a simple DllImport. No function pointers needed.

Otherwise, the function pointers should be prefered over marshaled delegates where possible. Using function pointers for interop is more performant, more AOT friendly, and it avoids the "callback on collected delegate" trap that one often falls into with marshaled delegates.

I have been converting marshaled delegates to function pointers throughout the repo. See #52192 that is still waiting for review - would you like to volunteer?