Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can Cython work with extern C API which has one parameter used as input and output buffer #441

Open
halehawk opened this issue May 31, 2023 · 11 comments

Comments

@halehawk
Copy link
Contributor

This is not a bug of numcodecs, I am working on some Cython codes using some extern C APIs. But I met some problems that the C API use one parameter as input and output buffers, do you know if Cython can work with C APIs to send in input array pointer and get the output array from the same pointer? Especially using Buffer and its pointer that is defined in numcodecs @jakirkham

@martindurant
Copy link
Member

You can certainly do this. It means, however (if I understood) that the C lib is allocating the buffer memory. You would probably make it into a buffer using fromMemory. You would need a cython class object to hold the pointer and dealloc when python collects the object. This obviously makes life more complicated and prone to crashes.

@halehawk
Copy link
Contributor Author

halehawk commented Jun 1, 2023 via email

@martindurant
Copy link
Member

Copying is, of course, the safer approach :)

@halehawk
Copy link
Contributor Author

halehawk commented Jun 1, 2023 via email

@martindurant
Copy link
Member

You mean https://github.com/NCAR/numcodecs_sperr ?

I believe the submodule tactic is complex and there have been conversations about avoiding it. There isn't a real reason for such a dependency to be included directly in numcodecs, rather than in a separate package referenced by an entrypoint.

Some codecs work by compiling the low-level C stuff into a binary and separate python bindings, which works particularly well with conda, which happily installs binary non-python dependencies. The cython part then only needs include statements.

@halehawk
Copy link
Contributor Author

halehawk commented Jun 1, 2023 via email

@martindurant
Copy link
Member

Do you think I can create a PR for this compressor in numcodecs?

In principle it can be OK, but I think you would find resistance to adding extra compile complexity or submodule into this package directly. Is there a reason not to make it a separate package?

@halehawk
Copy link
Contributor Author

halehawk commented Jun 1, 2023 via email

@martindurant
Copy link
Member

Two options:

  • sperr.pyx does not need to be in numcodecs, it can live in the same package as the C code
  • you can distribute your .so in a python wheel (hard) or a conda package (easy, but not as widely used; common in scientific scenarios, though)

@halehawk
Copy link
Contributor Author

halehawk commented Jun 1, 2023 via email

@martindurant
Copy link
Member

Perhaps check out what imagecodecs does. That includes all the C code in the repo, with bindings to expose both compress/uncompress functions and numcodecs codecs. It shows how you can call register at runtime or establish entrypoints for your codec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants