[C++] -fno-exceptions or not?

[tmmiko...@gmail.com]

Hi,

At the beginning I would like to admit that grpc is a very nice RPC solution. I'm looking for some areas when I could contribute to that project.

I've found various issues in the  implementation of DynamicThreadPool class (grpc/src/cpp/server/dynamic_thread_pool.*) and I've prepared a new straightforward and intuitive (IMHO!) implementation of that class + unit tests.

I compiled grpc with cmake (archlinux, gcc 7.2) and all was fine. Following documentation about running unit tests I've executed:

$ python2 ./tools/run_tests/run_tests.py -l c++ 

And only then I noticed that unit tests build uses -fno-exceptions flag in opposite to cmake build where that flag is not used (so exceptions are allowed).

Most of the issues found in the DynamicThreadPool concern the case when exceptions are enabled. But still there are issues even when the exceptions are disabled (for instance in case when memory allocation fails). 

Why different compiler flags are used? Should cmake build be considered as an experimental feature of grpc?

/Tomek

[Jan Tattermusch]

First of all, thanks for deciding to contribute to gRPC!

To answer your questions:

- When it comes to building on linux, using the Makefile is currently our primary way to build gRPC. cmake support is not experimental, but it has more importance on other platforms (like Windows), where you can't really use Makefile to build (on linux, cmake can be useful if you're crosscompiling for a different plaform)

- It is possible that our Makefile and CMakeLists.txt are not fully in sync in terms of compilations options - like the problem you found. Most of the times, this is not intended and the builds should be as similar as is reasonably possible (as these are basically just two ways of building the same thing). Because Makefile 

is currently our primary way of building on Linux, usually its compilation options for linux will be a bit more fine-tuned. In this case, you're welcome to create a PR that adds the -fno-exceptions to our cmake linux build as well.

- In the future, bazel will become the primary way to build gRPC (at least that's the plan), but we're not quite there yet.

- we know there are some flaws to our current cmake solution (see issue tracker) and we are working on fixing them, but most of them are windows related - as cmake is the primary way of building gRPC on Windows.

Hope this helps,

Jan