Expose uv_loop_t pointer for integration with other C-extensions

[pranavtbhat]

This PR adds a couple of functions to expose the raw uvloop pointer as int/pycapsule. #307

I can remove the int one if we feel it's not required.

[ghost]

uint64_t is not guaranteed to be the size of void *, why not use the dedicated feature and get it right with one single function?

[pranavtbhat]

@1st1 Your thoughts on pycapsule vs int?

[pranavtbhat]

The build failure looks unrelated.

[XeCycle]

My +1 on this feature; regarding uint64_t, uintptr_t may be better. FWIW there are existing libraries exposing pointers as integers (e.g. numpy.ndarray.ctypes.data); integers are easier to work with when using cffi.

[jensbjorgensen]

Hello, I'm interested in this feature and actually was checking outstanding pull requests before submitting my own. Looking over the above the failed check seems unrelated but as reviewer noted the integer should be uintptr_t not uint64_t. I'm not sure how/if it's possible for me to patch the submitted pull request. Should I submit my own?

[fantix]

Thanks for the PR and sorry for the delay! I think having an int pointer in Python doesn't make much sense - it'll be used in a C context anyways, so I think it's fine to only go with the standard API. (I was suggesting the Cython API in another PR, but I like the capsule better - just importing is sufficient, no linking needed!)

I pushed a fix with a Cython test that actually checks the encapsulated pointers.

[pwuertz]

Two questions on this

• Is there a new uvloop release on the horizon that includes this feature? ;)

• Any words of caution concerning libuv API compatibility? Is uvloop using a statically linked libuv library or a shared library that we'd re-use in a c-extension? Does uvloop use a vanilla libuv for which we can expect SemVer ABI stability?

[fantix]

• Is there a new uvloop release on the horizon that includes this feature? ;)

Yes, we'll try to release a new version in the next week or two.

• Any words of caution concerning libuv API compatibility?

Hmm we should probably re-export some of the libuv version-checking utils if we're statically linking, @1st1 wdyt?

Is uvloop using a statically linked libuv library or a shared library that we'd re-use in a c-extension?

This depends, by default it is statically linked but this can be override with the --use-system-libuv option.

Does uvloop use a vanilla libuv for which we can expect SemVer ABI stability?

Yes, https://github.com/MagicStack/uvloop/tree/master/vendor

[fantix]

• Any words of caution concerning libuv API compatibility?

Hmm we should probably re-export some of the libuv version-checking utils if we're statically linking, @1st1 wdyt?

uv_version() is now exposed in #491.