zmq_poll function missing ? about perlzmq HOT 11 CLOSED

can you not use either the non-blocking interface (poll on get_fd) or use has_pollin directly? See the non-blocking and pub/sub examples. I'm not necessarily against implementing a 1:1 zmq_poll binding, but personally I've never needed it and instead use a non-blocking solution. This seems like the modern, idiomatic Perl way to solve this.

from perlzmq.

@garnier-quentin I'm going to close this for now as I feel the non-blocking interface is both sufficient and preferred. But if you (or anyone else) feels strongly about this let me know.

from perlzmq.

Ok for the non-blocking example. But can we do it with 2..X fd ? I prefer the libzmq bindings. It masks how it works with fd or else.

from perlzmq.

sorry I don't understand, could you provide an example of what you're asking for?

from perlzmq.

Yes. I would like to do the same:

$polls = [
        {
            socket  => $internal_socket,
            events  => ZMQ_POLLIN,
            callback => \&router_internal_event,
        },
        {
            socket  => $external_socket,
            events  => ZMQ_POLLIN,
            callback => \&router_external_event,
        }
    ];

   while (1) {
      zmq_poll($polls , 5000);
      ....
   }

from perlzmq.

Can you give a compelling reason why that is preferable to:

my $internal_watcher =
    AE::io $internal_socket->get_fd, 0, \&router_internal_event;

my $external_watcher =
    AE::io $external_socket->get_fd, 0, \&router_external_event;

EV::run;

a manual IO poll while loop is quite icky in this day and age...

from perlzmq.

Because i need to do some treatments. "oldie but goodie" :)

from perlzmq.

treatments?

from perlzmq.

Not the good word. Sorry. Need to execute some codes. Like: checking death of my childs for example.
You can show the code here: https://github.com/centreon/centreon/blob/master/bin/centreond/centreon/script/centreondcore.pm

from perlzmq.

ok, so instead of doing

sub waiting_ready {
    my (%options) = @_;

    return 1 if (${$options{ready}} == 1);

    my $time = time();
    # We wait 10 seconds
    while (${$options{ready}} == 0 &&
           time() - $time < 10) {
        zmq_poll($centreond->{poll}, 5000);
    }

    if (${$options{ready}} == 0) {
        return 0;
    }

    return 1;
}

do

sub waiting_ready {
    my (%options) = @_;

    return 1 if (${$options{ready}} == 1);

    # We wait 10 seconds
    my $t = AE::timer 10, 0, sub { EV::break };

    my $internal_watcher =
        AE::io $internal_socket->get_fd, 0, \&router_internal_event;

    my $external_watcher =
        AE::io $external_socket->get_fd, 0, \&router_external_event;

    EV::run;

    if (${$options{ready}} == 0) {
        return 0;
    }

    return 1;
}

or somesuch. why is that not possible? Any place you see while (1) { ... zmq_poll ... } can easily be swapped with equivalent anyevent code.

Are you asking for an identical ZMQ::LibZMQ interface just to save you the effort of updating your legacy code? If so, while I sympathize, that's not a valid justification for changing (or in this case adding to) the API. Being backwards compatible with ZMQ::LibZMQ isn't one of the design goals for ZMQ::FFI.

from perlzmq.

Thanks for the response and the code. I'll try. It should be ok :)

from perlzmq.