Expose ability to deep-copy a context #236

1. 
   apoelstra commented at 7:08 pm on April 11, 2015: contributor

   For the Rust bindings (and likely for binding to other languages which hide memory management from the user) I need to be able to deep-copy a secp256k1 context. This exposes a secp256k1_context_clone function which serves this purpose.
2. 
   gmaxwell commented at 11:13 pm on April 11, 2015: contributor

   ACK.
3. 
   sipa commented at 2:26 am on April 12, 2015: contributor

   I don’t think this code will work for anything but a VERIFY + SIGN initialized context.
4. 
   apoelstra commented at 2:53 am on April 12, 2015: contributor

   Eek, you’re right @sipa.
5. apoelstra force-pushed on Apr 12, 2015
6. 
   apoelstra commented at 3:13 am on April 12, 2015: contributor

   I’ve pushed a new version which behaves properly for all context types, and tests that they work correctly.
7. Expose ability to deep-copy a context d899b5b67c
8. apoelstra force-pushed on Apr 12, 2015
9. 
   sipa commented at 9:05 am on April 12, 2015: contributor

   ACK
10. sipa merged this on Apr 12, 2015
11. sipa closed this on Apr 12, 2015

    ---

12. sipa referenced this in commit 9688030874 on Apr 12, 2015
13. 
    DavidEGrayson commented at 4:47 pm on April 12, 2015: none

    For the Rust bindings (and likely for binding to other languages which hide memory management from the user) I need to be able to deep-copy a secp256k1 context.

    A few months ago, before pull request #208 was merged, I made a Ruby binding for secp256k1 which uses contexts. I store the context pointer in an FFI::AutoPointer object. When that object gets garbage collected, it calls secp256k1_context_destroy on the underlying pointer. (If I had written the binding in C instead of using FFI, I could have accomplished the same thing.)

    So does Rust really require you to be able to deep copy objects like this? Libusb’s contexts do not have a clone feature but it looks like someone made a Rust binding for Libusb. I know very little about Rust, sorry.

14. 
    apoelstra commented at 5:22 pm on April 12, 2015: contributor

    @DavidEGrayson The short answer is no; I could avoid this either by hurting usability for users of my bindings, or by introducing synchronization primitives to share data rather than cloning it.

    The long answer:

    No, I could just keep it in an atomic refcount wrapper for example, which would give similar behaviour to Ruby. But then I’m introducing a dependency on Rust’s runtime; rust-secp256k1 makes a point of never using Rust’s allocator or synchronization primitives to ensure it can be use in very limited environments. (I haven’t measured but I’d also expect that in many contexts copying a couple hundred bytes will be faster than using the refcount, both because of the cost of atomic operations and because you’d need a pointer which is accessible from multiple threads; in any case it’s easy for a user to add refcounting if the bindings don’t, and not easy to remove it if the bindings do.)

    The Libusb bindings provide a Rust Context object to users of its API, but this cannot be copied in any way, which forces users who need copies either to create new ones or to use some other synchronization wrapper. (And for libusb, atomic refcounts are not sufficient because libusb contexts are mutated in use, so a more expensive synchronization primitive like a mutex would be needed.)

    Finally, secp256k1 contexts are really expensive to create from scratch, and are needed for things like validating that keys are well-formed, which isn’t naturally tied to any long-lived object that could hold a context. My guess is that libusb’s contexts are fairly cheap to create and that in practice they tend to be tied to some sort of object representing a USB device, so they don’t need to be created that often anyway.

15. 
    DavidEGrayson commented at 5:46 pm on April 12, 2015: none

    That makes sense, thanks!
16. apoelstra deleted the branch on Jun 19, 2017

Contributors
apoelstra gmaxwell sipa DavidEGrayson