GithubHelp home page GithubHelp logo

joyrex2001 / grpc-perl Goto Github PK

View Code? Open in Web Editor NEW
33.0 33.0 12.0 236 KB

Perl 5 implementation of gRPC using the official gRPC shared library.

License: Apache License 2.0

XS 25.83% Perl 62.50% C 11.47% Dockerfile 0.19%
grpc grpc-library grpc-perl perl

grpc-perl's People

Contributors

baryshevs avatar binarin avatar bleargh45 avatar fweimer-rh avatar joyrex2001 avatar laustbn avatar mbarbon avatar musicinmybrain avatar szabgab avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

Forkers

hexfusion mbarbon binarin jaberwoky ji0nghan bleargh45 baryshevs fgasper musicinmybrain fweimer-rh laustbn

grpc-perl's Issues

Stable Release?

@joyrex2001 Hello I would love to see this module on CPAN. Do you have a list of tasks that are required to move towards a stable release? I would like to try and help this effort.

Unit test "t/02-call.t" hangs for 40 seconds with recent versions of libgrpc

I noticed this while building the library on Debian Bookworm. The test t/02-call.t consistently takes 40 seconds to complete with recent versions of the gRPC library. It seems to get stuck during the first sub-test. It still passes eventually and other tests are quick. Is this expected?

Steps to reproduce:

apt -y install git build-essential libgrpc-dev libdevel-checklib-perl
git clone https://github.com/joyrex2001/grpc-perl
cd grpc-perl
perl Makefile.PL
make
make test

Output (look at wallclock secs)

Debian Buster (libgrpc 1.16.1-1)

root@grpc-test-buster:~/grpc-perl# PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/02-call.t
t/02-call.t .. ok
All tests successful.
Files=1, Tests=15,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.02 cusr  0.01 csys =  0.04 CPU)
Result: PASS

Bullseye (libgrpc 1.30.2-3)

root@grpc-test-bullseye:~/grpc-perl# PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/02-call.t
t/02-call.t .. ok
All tests successful.
Files=1, Tests=15,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.03 cusr  0.00 csys =  0.04 CPU)
Result: PASS

Bookworm (libgrpc 1.51.1-3+b1)

root@grpc-test-bookworm:~/grpc-perl# PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/02-call.t
t/02-call.t .. ok
All tests successful.
Files=1, Tests=15, 40 wallclock secs ( 0.01 usr  0.00 sys +  0.04 cusr  0.01 csys =  0.06 CPU)
Result: PASS

I also built v1.45.3 from source, both to try an intermediate version and to get debug symbols. It had the same behavior. I captured a stack trace from that version showing where it gets stuck:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f0ccc369c66 in epoll_wait (epfd=4, events=0x7f0ccbd2d064 <g_epoll_set+4>, maxevents=100, timeout=-1)
    at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30	../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.
(gdb) bt
#0  0x00007f0ccc369c66 in epoll_wait (epfd=4, events=0x7f0ccbd2d064 <g_epoll_set+4>, maxevents=100, timeout=-1)
    at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1  0x00007f0ccb89aafd in do_epoll_wait(grpc_pollset*, grpc_core::Timestamp) () from /root/local/lib/libgrpc.so.23
#2  0x00007f0ccb89bb22 in pollset_work(grpc_pollset*, grpc_pollset_worker**, grpc_core::Timestamp) () from /root/local/lib/libgrpc.so.23
#3  0x00007f0ccb8a7b0d in pollset_work(grpc_pollset*, grpc_pollset_worker**, grpc_core::Timestamp) () from /root/local/lib/libgrpc.so.23
#4  0x00007f0ccb8ae0a5 in grpc_pollset_work(grpc_pollset*, grpc_pollset_worker**, grpc_core::Timestamp) ()
   from /root/local/lib/libgrpc.so.23
#5  0x00007f0ccb97f92f in cq_pluck(grpc_completion_queue*, void*, gpr_timespec, void*) () from /root/local/lib/libgrpc.so.23
#6  0x00007f0ccb97fc0d in grpc_completion_queue_pluck () from /root/local/lib/libgrpc.so.23
#7  0x00007f0ccc1649bd in XS_Grpc__XS__Call_startBatch () from /root/grpc-perl/blib/arch/auto/Grpc/XS/XS.so
#8  0x00005644e8257f18 in Perl_pp_entersub (my_perl=0x5644e889f2a0) at ./build-static/pp_hot.c:5357
#9  0x00005644e824def6 in Perl_runops_standard (my_perl=0x5644e889f2a0) at ./build-static/run.c:41
#10 0x00005644e81ac779 in S_run_body (oldscope=<optimized out>, my_perl=<optimized out>) at ./build-static/perl.c:2721
#11 perl_run (my_perl=0x5644e889f2a0) at ./build-static/perl.c:2644
#12 0x00005644e817e4b2 in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at ./build-static/perlmain.c:110

I wonder if the 40 seconds are some kind of internal timeout in the eventloop inside libgrpc?

I originally wanted to test against all older releases of libgrpc, to learn when the regression was introduced, but ran into compilation issues with Abseil (one of the dependencies) and gave up for the time being.

t/17-fork_friendliness.t hangs on Ubuntu20/aarch64

Output from the test suite when I try to install:

t/10-base_stub.t .............. ok
t/11-bidi_streaming_call.t .... ok
t/12-client_streaming_call.t .. ok
t/13-server_streaming_call.t .. ok
t/14-unary_call.t ............. ok
t/15-xs_end_to_end.t .......... 1/82 Expected hash for create_metadata_array() args at t/15-xs_end_to_end.t line 298.
Expected hash for create_metadata_array() args at t/15-xs_end_to_end.t line 341.
t/15-xs_end_to_end.t .......... ok
t/16-xs_secure_end_to_end.t ... 1/46 Expected hash for create_metadata_array() args at t/16-xs_secure_end_to_end.t line 270.
t/16-xs_secure_end_to_end.t ... ok
t/17-fork_friendliness.t ...... 1/?

Changes required to support grpc 1.45.0 and later

In grpc version 1.45.0 and later, “Eliminate gRPC insecure build” is implemented.

This affects channel creation:

grpc-perl/ext/channel.xs

Lines 39 to 45 in 6c73245

if (creds == NULL) {
ctx->wrapped = grpc_insecure_channel_create(target, &args, NULL);
} else {
gpr_log(GPR_DEBUG, "Initialized secure channel");
ctx->wrapped =
grpc_secure_channel_create(creds->wrapped, target, &args, NULL);
}

The grpc_insecure_channel_create function is removed, and grpc_secure_channel_create becomes grpc_channel_create:

/** Creates a secure channel using the passed-in credentials. Additional
    channel level configuration MAY be provided by grpc_channel_args, though
    the expectation is that most clients will want to simply pass NULL. The
    user data in 'args' need only live through the invocation of this function.
    However, if any args of the 'pointer' type are passed, then the referenced
    vtable must be maintained by the caller until grpc_channel_destroy
    terminates. See grpc_channel_args definition for more on this. */
GRPCAPI grpc_channel* grpc_channel_create(const char* target,
                                          grpc_channel_credentials* creds,
                                          const grpc_channel_args* args);

I think it should still be possible to create an insecure channel by using the experimental API function grpc_insecure_credentials_create from grpc/grpc_security.h:

/**
 * EXPERIMENTAL API - Subject to change
 *
 * This method creates an insecure channel credentials object.
 */
GRPCAPI grpc_channel_credentials* grpc_insecure_credentials_create();

I ran across this while updating the grpc package in Fedora Linux.

Unicode bug?

Hello,

I’m looking over this library and notice a lot of use of plain SvPV. This causes Unicode-handling bugs, such as can be seen if you apply this patch:

diff --git a/t/01-call_credentials.t b/t/01-call_credentials.t
index c22dc5a..725a4f5 100644
--- a/t/01-call_credentials.t
+++ b/t/01-call_credentials.t
@@ -105,7 +105,8 @@ ok($event->{method} eq '/abc/dummy_method',"event->method has wrong value");
 # print STDERR "event=".Dumper($event);
 # Dump($event);

-my $status_text = 'xyz';
+my $status_text = "\xe9xyz";
+utf8::upgrade($status_text);
 my $server_call = $event->{call};
 $event = $server_call->startBatch(
     Grpc::Constants::GRPC_OP_SEND_INITIAL_METADATA() => {},

Am I right in thinking that all strings into and out of this module are meant to be byte buffers? That being the case, the sensible fix would be to replace SvPV and SvPV_nolen with SvPVbyte and SvPVbyte_nolen, respectively. It would be a breaking change, though, for anything that depends on the current behaviour.

build on Ubuntu 14.04 issue

Hello, there is an issue when build on Ubuntu 14.04

/usr/bin/perl /usr/share/perl/5.18/ExtUtils/xsubpp -typemap /usr/share/perl/5.18/ExtUtils/typemap -typemap typemap Grpc.xs > Grpc.xsc && mv Grpc.xsc Grpc.c
Please specify prototyping behavior for Grpc.xs (see perlxs manual)
cc -c -I. -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION="0.1" -DXS_VERSION="0.1" -fPIC "-I/usr/lib/perl/5.18/CORE" Grpc.c
./ext/call.xs: In function ‘XS_Grpc__XS__Call_startBatch’:
./ext/call.xs:94:49: error: ‘struct ’ has no member named ‘maybe_compression_level’
ops[op_num].data.send_initial_metadata.maybe_compression_level.is_set=0;
^
./ext/constants.xs: In function ‘XS_Grpc__XS__Constants_CHANNEL_FATAL_FAILURE’:
./ext/constants.xs:244:14: error: ‘GRPC_CHANNEL_SHUTDOWN’ undeclared (first use in this function)
RETVAL = GRPC_CHANNEL_SHUTDOWN;
^
./ext/constants.xs:244:14: note: each undeclared identifier is reported only once for each function it appears in

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.