No description provided.
Add doc/ folder, split up readme and add more usage documentation #55
pull ryanofsky wants to merge 2 commits into bitcoin-core:master from ryanofsky:pr/doc changing 4 files +78 −58-
ryanofsky commented at 9:10 PM on July 20, 2021: collaborator
-
5539208883
Split up README.md
Move sections to new doc/design.md, doc/install.md, doc/usage.md files. Also add link to issue tracker.
-
1a3dc8d263
Add documentation about interface definitions
From https://github.com/bitcoin/bitcoin/pull/19160#discussion_r587445671
- ryanofsky merged this on Jul 20, 2021
- ryanofsky closed this on Jul 20, 2021
-
ryanofsky commented at 11:25 PM on July 20, 2021: collaborator
Updated comment where this was suggested https://github.com/bitcoin/bitcoin/pull/19160#discussion_r604066654
-
ariard commented at 6:11 PM on July 21, 2021: none
Post-merge ACK 1a3dc8d, thanks for taking the suggestion!
One of the hurdle I've met is how to pass interface pointers cleanly across processes to enable bidirectional requests. IIRC, this is illustrated in
example/though it could be nice to highlight in usage as from my experience it's one of the most interesting feature of capnproto :) -
ryanofsky commented at 6:37 PM on July 21, 2021: collaborator
One of the hurdle I've met is how to pass interface pointers cleanly across processes to enable bidirectional requests. IIRC, this is illustrated in
example/though it could be nice to highlight in usage as from my experience it's one of the most interesting feature of capnproto :)Thanks this is good to know, and I'll make a note to write a description.
I will say a complication of passing interface pointers is ownership semantics. The thing that works best is to use
std::unique_ptr<Interface>return values and arguments.std::shared_ptr<Interface>works too but you can have trouble with leaks and circular references if you're not careful.Interface&andInterface*return values and arguments which are used by some bitcoin interfaces are messy and painful and I'm trying to gradually get rid of them (CScheduler and RPCTimer stuff is really messy). Would definitely recommend usingunique_ptrwherever possible in all new methods. Looking briefly atsrc/interfaces/in https://github.com/ariard/bitcoin/commits/2021-07-altnet-lightning I didn't actually see new methods passing interfaces around exceptInit::makeXXXmethods, but avoidingInterface&orInterface*arguments could be a good tip for the future -
ariard commented at 4:59 PM on July 23, 2021: none
Sorry the code is a mess, I think here is an example of passing interface pointers : https://github.com/ariard/bitcoin/blob/76c82fc7cbba554fbcfd2f9dfff02c338e75f051/src/interfaces/init.h#L40
Where a pointer on the
Validationinterface is passed from thebitcoin-nodeto thebitcoin-altnetprocess. TheValidationinterface is defined here : https://github.com/ariard/bitcoin/blob/2021-07-altnet-lightning/src/interfaces/validation.h. I think it's interface pointers but I might on another feature, just using the wrong name?And yeah really true on the ownership semantics, I did end up by using
std::unique_ptr<Interface>everywhere though only after trying and failing the other alternatives... -
ryanofsky commented at 5:26 PM on July 23, 2021: collaborator
And yeah really true on the ownership semantics, I did end up by using
std::unique_ptr<Interface>everywhere though only after trying and failing the other alternatives...Yes, I think using unique_ptr is a good thing. It ensures that all the objects shared across processes have a clear owner. It also encourages objects which are shared across processes to be lightweight wrappers, so the cross-process API that is exposed is separate from the actual implementation of features that are being provided.
- bitcoin-core locked this on Jun 25, 2025