busy results from the CPAN

Plack-App-MCCS

site near you, or see L<https://metacpan.org/module/Dist::Zilla::Plugin::Config::Git/>.

=for :stopwords cpan testmatrix url annocpan anno bugtracker rt cpants kwalitee diff irc mailto metadata placeholders metacpan

=head1 SUPPORT

=head2 Internet Relay Chat

You can get live help by using IRC ( Internet Relay Chat ). If you don't know what IRC is,
please read this excellent guide: L<http://en.wikipedia.org/wiki/Internet_Relay_Chat>. Please
be courteous and patient when talking to us, as we might be busy or sleeping! You can join
those networks/channels and get help:

=over 4

=item *

irc.perl.org

You can connect to the server at 'irc.perl.org' and talk to this person for help: SineSwiper.

local/lib/perl5/IO/Socket/SSL.pod view on Meta::CPAN

a C-style memory address of the peer's own certificate (convertible to
PEM form with Net::SSLeay::PEM_get_string_X509()).

=item 6.
The depth of the certificate in the chain. Depth 0 is the leaf certificate.

=back

The function should return 1 or 0, depending on whether it thinks the
certificate is valid or invalid.  The default is to let OpenSSL do all of the
busy work.

The callback will be called for each element in the certificate chain.

See the OpenSSL documentation for SSL_CTX_set_verify for more information.

=item SSL_verifycn_scheme

The scheme is used to correctly verify the identity inside the certificate
by using the hostname of the peer.
See the information about the verification schemes in B<verify_hostname>.

local/lib/perl5/IPC/Run/Timer.pm view on Meta::CPAN

		            |
			check $t

Adding a fudge of '1' in this example means that the timer is guaranteed
not to expire before tick 2.

The fudge is not added to an interval of '0'.

This means that intervals guarantee a minimum interval.  Given that
the process running perl may be suspended for some period of time, or that
it gets busy doing something time-consuming, there are no other guarantees on
how long it will take a timer to expire.

=head1 SUBCLASSING

INCOMPATIBLE CHANGE: Due to the awkwardness introduced by ripping
pseudohashes out of Perl, this class I<no longer> uses the fields
pragma.

=head1 FUNCTIONS & METHODS

local/lib/perl5/PPI.pm view on Meta::CPAN

L<https://metacpan.org/pod/PPI>

PPI source is maintained in a GitHub repository at the following address.

L<https://github.com/Perl-Critic/PPI>

Contributions via GitHub pull request are welcome.

Bug fixes in the form of pull requests or bug reports with
new (failing) unit tests have the best chance of being addressed
by busy maintainers, and are B<strongly> encouraged.

If you cannot provide a test or fix, or don't have time to do so,
then regular bug reports are still accepted and appreciated via the
GitHub bug tracker.

L<https://github.com/Perl-Critic/PPI/issues>

The C<ppidump> utility that is part of the L<Perl::Critic> distribution
is a useful tool for demonstrating how PPI is parsing (or misparsing)
small code snippets, and for providing information for bug reports.

local/lib/perl5/Plack/Handler/FCGI.pm view on Meta::CPAN

            die "Bad response $res";
        }

        # give pm_post_dispatch the chance to do things after the client thinks
        # the request is done
        $request->Finish;

        $proc_manager && $proc_manager->pm_post_dispatch();

        # When the fcgi-manager exits it sends a TERM signal to the workers.
        # However, if we're busy processing the cleanup handlers, testing
        # shows that the worker doesn't actually exit in that case.
        # Trapping the TERM signal and finshing up fixes that.
        my $exit_due_to_signal = 0;
        if ( @{ $env->{'psgix.cleanup.handlers'} || [] } ) {
            local $SIG{TERM} = sub { $exit_due_to_signal = 1 };
            for my $handler ( @{ $env->{'psgix.cleanup.handlers'} } ) {
                $handler->($env);
            }
        }

local/lib/perl5/x86_64-linux-thread-multi/AnyEvent.pm view on Meta::CPAN


IO::Async performs very well when using its epoll backend, and still quite
good compared to Glib when using its pure perl backend.

Event suffers from high setup time as well (look at its code and you will
understand why). Callback invocation also has a high overhead compared to
the C<< $_->() for .. >>-style loop that the Perl event loop uses. Event
uses select or poll in basically all documented configurations.

Glib is hit hard by its quadratic behaviour w.r.t. many watchers. It
clearly fails to perform with many filehandles or in busy servers.

POE is still completely out of the picture, taking over 1000 times as long
as EV, and over 100 times as long as the Perl implementation, even though
it uses a C-based event loop in this case.

=head3 Summary

=over 4

=item * The pure perl implementation performs extremely well.

local/lib/perl5/x86_64-linux-thread-multi/AnyEvent/Handle.pm view on Meta::CPAN

See also the next question, which explains this in a bit more detail.

=item How can I serve requests in a loop?

Most protocols consist of some setup phase (authentication for example)
followed by a request handling phase, where the server waits for requests
and handles them, in a loop.

There are two important variants: The first (traditional, better) variant
handles requests until the server gets some QUIT command, causing it to
close the connection first (highly desirable for a busy TCP server). A
client dropping the connection is an error, which means this variant can
detect an unexpected detection close.

To handle this case, always make sure you have a non-empty read queue, by
pushing the "read request start" handler on it:

   # we assume a request starts with a single line
   my @start_request; @start_request = (line => sub {
      my ($hdl, $line) = @_;

local/lib/perl5/x86_64-linux-thread-multi/AnyEvent/IO.pm view on Meta::CPAN


Unlike L<AnyEvent>, which model to use is currently decided at module load
time, not at first use. Future releases might change this.

=head2 RATIONALE

While disk I/O often seems "instant" compared to, say, socket I/O, there
are many situations where your program can block for extended time periods
when doing disk I/O. For example, you access a disk on an NFS server and
it is gone - can take ages to respond again, if ever. Or your system is
extremely busy because it creates or restores a backup - reading data from
disk can then take seconds. Or you use Linux, which for so many years has
a close-to-broken VM/IO subsystem that can often induce minutes or more of
delay for disk I/O, even under what I would consider light I/O loads.

Whatever the situation, some programs just can't afford to block for long
times (say, half a second or more), because they need to respond as fast
as possible.

For those cases, you need asynchronous I/O.

local/lib/perl5/x86_64-linux-thread-multi/AnyEvent/Impl/FLTK.pm view on Meta::CPAN

      FLTK::WRITE | (AnyEvent::WIN32 ? FLTK::EXCEPT : 0);

   # fltk hardcodes poll constants and aliases EXCEPT with POLLERR,
   # which is grossly wrong, but likely it doesn't use poll on windows.
   FLTK::add_fd $fh, $ev, sub { &$cb }
}

# use signal and child emulation - fltk has no facilities for that

# fltk idle watchers are like EV::check watchers, and fltk check watchers
# are like EV::prepare watchers. both are called when the loop is busy,
# so we have to use idle watcher emulation.

sub _poll {
   FLTK::wait;
}

sub AnyEvent::CondVar::Base::_wait {
   FLTK::wait until exists $_[0]{_ae_sent};
}

local/lib/perl5/x86_64-linux-thread-multi/AnyEvent/Log.pm view on Meta::CPAN

This of course works for any package, not just L<AnyEvent::Debug>, but
assumes the log level for AnyEvent::Debug hasn't been changed from the
default.

=back

=head1 ASYNCHRONOUS DISK I/O

This module uses L<AnyEvent::IO> to actually write log messages (in
C<log_to_file> and C<log_to_path>), so it doesn't block your program when
the disk is busy and a non-blocking L<AnyEvent::IO> backend is available.

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://anyevent.schmorp.de

=cut

1

( run in 0.482 second using v1.01-cache-2.11-cpan-3cd7ad12f66 )