That lock does not synchronize with the modification in_uv_hook_close as far as I can tell - but regardless it's not a threading thing, so I don't fully understand it yet, as I said in the PR description - it just happens to work.

Ok, the basic issue is that whenuv_fseventscb_file is called with an error, weuvfinalize explicitly, which disassociates the julia struct and frees schedules the handle for freeing (but due to an oversight does not set the handle to NULL). There's a lot of noise after that, with bothclose anduvfinalize called again, but that's the basic fix.

That lock does not synchronize with the modification in_uv_hook_close as far as I can tell

I guess that is always called from inside the uv loop and as long as we require always holdiolock_begin while inside uv_run we're guaranteed to be holding that lock here, so the operative part of this is actually settinghandle toC_NULL duringuvfinalize.

@vtjnash any more comments?

Did we make sure to setuv.handle to NULL in the otheruvfinalize?

I did go through them and as far as I can tell this one was the only bad one.