Calling close on wrong thread should be avoided

[lodejard]

That can happen when a safehandle is GC'ed - to work this will actually need to queue to the loop handle to actually finish releasing?

[ThatRendle]

Anything doing anything to libuv needs to be executed on the loop thread or
you end up with AccessViolationExceptions all over the shop.

On Tuesday, 8 July 2014, Louis DeJardin [email protected] wrote:

That can happen when a safehandle is GC'ed - to work this will actually
need to queue to the loop handle to actually finish releasing?

—
Reply to this email directly or view it on GitHub
#16.

Mark Rendle
Founder, Zudio https://zud.io/

[ThatRendle]

Don't know if it's any help, or even relevant, but I ended up writing some thread-marshaling code to distribute requests off the libuv loop thread and marshal responses back onto it, mostly here: https://github.com/markrendle/FluxUv/blob/master/FluxUv/RequestDispatcher.cs

and here: https://github.com/markrendle/FluxUv/blob/master/FluxUv%2FFluxServer.cs#L74-L97

Everything relating to the libuv loop, handles, allocated memory, anything has to be done on the loop thread, it seems.

[lodejard]

Yep, exactly the same kind of thing. This particular bug is about marshalling back onto the loop thread in order to call uv_close when something like tcp safehandle is garbage collected. The gc happens on a random finalizer thread...