in reply to Re^2: Using Net::Server::Multiplex and polling Spread
in thread Using Net::Server::Multiplex and polling Spread

It does sound like you have to do your own event loop then, if you want to be able to catch Spread events even when there is no action to or from the clients. I don't see any obvious way to make this work with Net::Server::Multiplex. Maybe POE would be more appropriate.
  • Comment on Re^3: Using Net::Server::Multiplex and polling Spread

Replies are listed 'Best First'.
Re^4: Using Net::Server::Multiplex and polling Spread
by superfrink (Curate) on Jul 04, 2004 at 19:50 UTC
    N:S:M doesn't have a hook function inside the loop. If it did I could just set a timer using Time::HiRes to send a SIGALRM which I think would break out of the select() call that the process is blocked on and let a hook function run. After the hook the flow would move around to the select() again.

    Well I do have the source for N:S:M so... I just overrode the loop() function in my own program with a copy of the function by just changing the following bit of code from
    $mux->loop(sub { my ($rdready, $wrready) = @_; &check_sigs(); $mux->endloop if $prop->{_HUP}; });
    to
    $mux->loop(sub { my ($rdready, $wrready) = @_; &check_sigs(); $self->inner_loop_hook; # user customizable hook $mux->endloop if $prop->{_HUP}; });
    All I did was add the line:
    $self->inner_loop_hook; # user customizable hook
    And then I just defined my own hook function as:
    sub inner_loop_hook { print "Dude! " , time , "\n"; }
    I haven't tested any of this with Spread yet which will take a while yet. Also I setup a timer with these lines at the top of the program.
    use Time::HiRes qw( setitimer getitimer ITIMER_REAL ITIMER_VIRTUAL ITIMER_PROF ); setitimer(ITIMER_REAL, 3, 1); $SIG{ALRM} = sub { return };
    Which will wait 3 seconds before starting and then send a SIGALRM every 1 second after that.
      Sounds like it could work, if you implement your Spread polling inside the hook you added. I'm not sure what the alarm stuff is for. Isn't the whole point of select() that it doesn't block? Let us know how it works out.
        Isn't the whole point of select() that it doesn't block? Let us know how it works out.
        Not quite, select() does block until one of the following happens:
        1. One of the file descriptors is in a state where it will not block if use to read or write.
        2. Something exceptional happened to a file descriptor. (Like the other side of a network connection closed the connection.)
        3. A timeout expires. (Passed as an argument to the select() call.)
          Update: timeout can be zero which causes select to not block.
        4. A signal arrives. This lets the main loop of a process deal with events triggered by signals. (Usually the signal handler just sets a global flag and the main loop checks for the flag.)
        Some details based on the man page for select(2) found on my Linux system today. Your system might vary.