Proposal to allow C++ to be used in gRPC Core
Craig Tiller
Craig Tiller
Jan Tattermusch
Craig Tiller
Reread the proposal: one of the key requirements here is no libc++ dependency. We'll be using the C++ language, but in a way that avoids all the runtime baggage.
I expect some work for wrapped language folks here, and the implementation plan is careful to ensure we can roll back quickly if this fails (but I don't believe it will).
The advantage for some short term extra effort is a more maintainable and approachable core in perpetuity, and that's a huge advantage long term.
One implementation trick we used on Windows for Python and Ruby was to have two build environments: one for the extension (using whatever the platform required), and another for gRPC, using something more modern. We've got codegen smarts ready to go to dynamically load the c core bits from a DLL without even a link time dependency. I'm certain if we hit painful cases in other wrapped languages we can extend such an approach within days.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/2e080e70-29b0-4c60-9379-3459ffd3fa4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jan Tattermusch
Reread the proposal: one of the key requirements here is no libc++ dependency. We'll be using the C++ language, but in a way that avoids all the runtime baggage.
I expect some work for wrapped language folks here, and the implementation plan is careful to ensure we can roll back quickly if this fails (but I don't believe it will)
The advantage for some short term extra effort is a more maintainable and approachable core in perpetuity, and that's a huge advantage long term.
One implementation trick we used on Windows for Python and Ruby was to have two build environments: one for the extension (using whatever the platform required), and another for gRPC, using something more modern. We've got codegen smarts ready to go to dynamically load the c core bits from a DLL without even a link time dependency. I'm certain if we hit painful cases in other wrapped languages we can extend such an approach within days.
I remember we went through quite some trouble when trying to build C core so that it is compatible with wide range of libc versions. I expect things to become even worse when libc++ comes into play. My guesstimate is that introducing C++ into C core would cost 2 weeks of work & testing per wrapped language to make sure everything works the way it should (especially around the distribution packages & platform compatibility etc.)I'm not 100% sure if we could make things work for all languages without harming usability (but I can be convinced - it would be worth to experiment with one wrapped lang. before we decide to go ahead).
On Saturday, April 1, 2017 at 4:39:49 PM UTC+2, Craig Tiller wrote:--https://github.com/grpc/grpc/pull/10426 and https://github.com/grpc/grpc/pull/10427 start to show what this might look like.On Sat, Apr 1, 2017 at 7:33 AM Craig Tiller <cti...@google.com> wrote:I've created a proposal to allow C++ to be used in gRPC Core here: https://github.com/grpc/proposal/pull/21.I'm especially interested in hearing from folks in environments where this won't work well.
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
Carl Mastrangelo
Jan Tattermusch
Are C++ libraries substantially larger than there C counter parts? Binary size is a serious consideration for Java, perhaps it is for wrapped languages too?
On Saturday, April 1, 2017 at 7:34:06 AM UTC-7, Craig Tiller wrote:I've created a proposal to allow C++ to be used in gRPC Core here: https://github.com/grpc/proposal/pull/21.I'm especially interested in hearing from folks in environments where this won't work well.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c8ba5869-d372-4215-a5a5-2b492354b2a3%40googlegroups.com.
Craig Tiller
There's no apriori reason why this should increase binary size: C code compiled as C++ should end up approximately the same size, and we're not introducing new dependencies.
It's probably worth introducing something like a Bloaty McBloatface diff much as we do a benchmark diff, but I'd hold that's an orthogonal issue.
On Tue, Apr 4, 2017 at 2:51 AM, 'Carl Mastrangelo' via grpc.io <grp...@googlegroups.com> wrote:Are C++ libraries substantially larger than there C counter parts? Binary size is a serious consideration for Java, perhaps it is for wrapped languages too?In some wrapped languages, the distribution package contains the binary precompiled for 6 different targets (Linux,Win,Mac x x64,x86; possibly more in the future) so if there's a significant increase in size, it might be inconvenient at least.
On Saturday, April 1, 2017 at 7:34:06 AM UTC-7, Craig Tiller wrote:I've created a proposal to allow C++ to be used in gRPC Core here: https://github.com/grpc/proposal/pull/21.I'm especially interested in hearing from folks in environments where this won't work well.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c8ba5869-d372-4215-a5a5-2b492354b2a3%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CACF4M0T-DGAT27m4tdpAvG83Hv2Li%3D-w7UU2LucjzBU8T0%3Dzbw%40mail.gmail.com.
Nicolas Noble
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
Craig Tiller
As long as the public interfaces for grpc_ and gpr_ libs do not change, this library is not effected. Applications using this library link with libgrpc and libgpr. However, one of the reasons for applications to use libgrpc-c instead of libgrpc++ and generated C++ code is compiler support for C++11 in their environment. If gRPC core requires a compiler with C++11 support, they will be stuck with older gRPC release till they migrate to a latest compiler (which they should eventually). But this project will not be effected by this change. Thanks for reaching out.
Just like with basically everything else, I'd expect that only when exaggerating with the compiler, with excessive templating or code generation for instance. C++ in itself doesn't generate more code than C for the same piece of code. It's what you do with the code that does.
Are C++ libraries substantially larger than there C counter parts? Binary size is a serious consideration for Java, perhaps it is for wrapped languages too?
On Saturday, April 1, 2017 at 7:34:06 AM UTC-7, Craig Tiller wrote:I've created a proposal to allow C++ to be used in gRPC Core here: https://github.com/grpc/proposal/pull/21.I'm especially interested in hearing from folks in environments where this won't work well.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c8ba5869-d372-4215-a5a5-2b492354b2a3%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAEvr0PE3qw9_Di1tDTXjkT4S9wa%2ByeypZ55cSoA53rhHy-U-Pw%40mail.gmail.com.