Using libuv underneath

[jojy.v...@gmail.com]

Hi all

 We are contemplating using the libuv I/O interface in gRPC iomgr. How do we get that going? I tried building the source with :


CFLAGS="-DGRPC_UV -DGRPC_CUSTOM_IOMGR_THREAD_CHECK -DGRPC_CUSTOM_SOCKET" make


But when i build the examples, i get link errors , example

undefined reference to `grpc_ares_ev_driver_create_locked(grpc_ares_ev_driver**, grpc_pollset_set*, grpc_combiner*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_tcp_client_create_from_fd(grpc_fd*, grpc_channel_args const*, char const*)'

../../../libs/opt/libgrpc.so: undefined reference to `uv_default_loop'

I dont see much information on how to do this.

Any help is much appreciated

thanks

Jojy

[Michael Lumish]

Defining GRPC_UV just enables the code in the gRPC library that uses libuv. In order to actually use it, you also have to explicitly provide CFLAGS and LDFLAGS to point to the libuv headers and shared library.

I also have to warn you that the way that gRPC uses libuv is all based on the assumption that it will be used in the Node.js gRPC library. In particular, it assumes that the user is running the uv default loop, and will do so until uv_run returns 0. It also assumes that the user will be calling grpc_completion_queue_next whenever there are pending completion queue events. You can see how the Node gRPC library does that in this file: https://github.com/grpc/grpc-node/blob/ad9b9dc8d7837c8f61ec6a311fe27ac952420ade/packages/grpc-native-core/ext/completion_queue.cc

--
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/4049ed23-278b-4736-96f9-ecbc98bffc1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jojy.v...@gmail.com]

Thanks for the response.

I understand that i will have to add CFLAGS and LDFLAGS for libuv.  I have already done that by editing the test Makefiles. If you notice, the link errors are not libuv related errors.

The need for us to explore libuv implementation is that we already have a libuv based event loop in our code. So we are trying to reuse it.

thanks again

[jojy.v...@gmail.com]

To clarify, here is the full list of link errors:



../../../libs/opt/libgrpc.so: undefined reference to `grpc_ares_ev_driver_start_locked(grpc_ares_ev_driver*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_ares_ev_driver_shutdown_locked(grpc_ares_ev_driver*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_ares_ev_driver_destroy_locked(grpc_ares_ev_driver*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_ares_ev_driver_create_locked(grpc_ares_ev_driver**, grpc_pollset_set*, grpc_combiner*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_tcp_client_create_from_fd(grpc_fd*, grpc_channel_args const*, char const*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_ares_ev_driver_get_channel_locked(grpc_ares_ev_driver*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_ipv6_loopback_available()'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_tcp_create(grpc_fd*, grpc_channel_args const*, char const*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_fd_create(int, char const*, bool)'

thanks

Jojy

[Michael Lumish]

I think that you may have incompatible constants defined in your CFLAGS. I would suggest looking at the binding.gyp file from the Node gRPC library here: https://github.com/grpc/grpc-node/blob/ad9b9dc8d7837c8f61ec6a311fe27ac952420ade/packages/grpc-native-core/binding.gyp. The defines appear in a couple of different places, but it does not define "GRPC_CUSTOM_IOMGR_THREAD_CHECK" or "GRPC_CUSTOM_SOCKET". I suspect that one or both of those is the problem.

--

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/18ed1c01-5208-4f29-b525-c657e2f1ddf0%40googlegroups.com.

[jojy.v...@gmail.com]

Thanks. 

I changed the CPPFLAGS to 

Now my link errors are reduced to:

../../../libs/opt/libgrpc.so: undefined reference to `grpc_tcp_client_create_from_fd(grpc_fd*, grpc_channel_args const*, char const*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_tcp_create(grpc_fd*, grpc_channel_args const*, char const*)'

../../../libs/opt/libgrpc.so: undefined reference to `grpc_fd_create(int, char const*, bool)'

So i think there are still things not right.

-Jojy

[jojy.v...@gmail.com]

Sorry i missed the flags i used: 

-DGRPC_UV -DGRPC_ARES=0 -DGPR_BACKWARDS_COMPATIBILITY_MODE

-Jojy

[Michael Lumish]

I should have realized this earlier: by default make builds the C++ library, and I'm not sure if that's what you want, but I have never before attempted to build the C++ library with libuv support. I think it depends on internal core functions that the libuv iomgr doesn't implement. If you don't intend to build the C++ library and you just want to build the core, I think you want to do "make grpc".

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/2d9cd3b8-793d-4151-b186-351479084401%40googlegroups.com.

[jojy.v...@gmail.com]

Thanks Michael.

Our codebase is C++. We already use a libev based event loop. Our plan is to port our libev based implementations to libuv and then use the libuv based gRPC implementation for RPC. 

I was able to build the C++ library by "ifdef" magic. Essentially, i had to "ifdef" out suppport for  GPR_SUPPORT_CHANNELS_FROM_FD from a few files :

cpp/client/create_channel_posix.cc
core/ext/transport/chttp2/server/insecure/server_chttp2_posix.cc
core/ext/transport/chttp2/client/insecure/channel_create_posix.cc

Now I would think that since the above files are posix based, it should be ok. But I am not entirely sure about its impact.

thanks

Jojy