Result:
found more than 806 distributions - search limited to the first 2001 files matching your query
( run in 2.403 )
Dist-Zilla-TravisCI
view release on metacpan or search on metacpan
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:
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:
* irc.perl.org
You can connect to the server at 'irc.perl.org' and talk to this
DocSet
view release on metacpan or search on metacpan
examples/site/src/docs/2.0/os/win32/install.pod view on Meta::CPAN
As described in the discussion of issues in L<multithreaded
win32|docs::1.0::os::win32::multithread>, a mod_perl 1.0 enabled server
based on Apache 1.3 on Win32 is limited to a single thread serving a
request at a time. This effectively prevents concurrent processing,
which can have serious implications for busy sites. This problem is
addressed in the multi-thread/multi-process approach of mod_perl
2.0/Apache 2.0. This document discusses how to obtain mod_perl 2.0.
=head1 Installing
Docker-Client
view release on metacpan or search on metacpan
share/specs/v1.25.yaml view on Meta::CPAN
Author: ""
Created: "2015-09-10T08:30:53.26995814Z"
GraphDriver:
Name: "aufs"
RepoDigests:
- "localhost:5000/test/busybox/example@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf"
RepoTags:
- "example:1.0"
- "example:latest"
- "example:stable"
Config:
share/specs/v1.25.yaml view on Meta::CPAN
Images:
-
Id: "sha256:2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749"
ParentId: ""
RepoTags:
- "busybox:latest"
RepoDigests:
- "busybox@sha256:a59906e33509d14c036c8678d687bd4eec81ed7c4b8ce907b888c607f6a1e0e6"
Created: 1466724217
Size: 1092588
SharedSize: 0
VirtualSize: 1092588
Labels: {}
share/specs/v1.25.yaml view on Meta::CPAN
Containers:
-
Id: "e575172ed11dc01bfce087fb27bee502db149e1a0fad7c296ad300bbff178148"
Names:
- "/top"
Image: "busybox"
ImageID: "sha256:2b8fd9751c4c0f5dd266fcae00707e67a2545ef34f9a29354585f93dac906749"
Command: "top"
Created: 1472592424
Ports: []
SizeRootFs: 1092588
share/specs/v1.25.yaml view on Meta::CPAN
- type: "object"
example:
Name: "top"
TaskTemplate:
ContainerSpec:
Image: "busybox"
Args:
- "top"
Resources:
Limits: {}
Reservations: {}
Docker-Names-Random
view release on metacpan or search on metacpan
lib/Docker/Names/Random.pm view on Meta::CPAN
I<interesting_mendeleev>,
I<epic_engelbart>,
I<lucid_dhawan>,
I<recursing_cori>,
I<ecstatic_liskov> and
I<busy_ardinghelli>.
The combination I<boring_wozniak> is not allowed because
L<Steve Wozniak|https://en.wikipedia.org/wiki/Steve_Wozniak> is not boring.
This same limitation exists in the
L<original code|https://github.com/moby/moby/blob/master/pkg/namesgenerator/names-generator.go>.
lib/Docker/Names/Random.pm view on Meta::CPAN
- word: beautiful
- word: blissful
- word: bold
- word: boring
- word: brave
- word: busy
- word: charming
- word: clever
- word: cool
- word: compassionate
- word: competent
Doxygen-Lua
view release on metacpan or search on metacpan
example/Doxyfile view on Meta::CPAN
# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
# determine which symbols to keep in memory and which to flush to disk.
# When the cache is full, less often used symbols will be written to disk.
# For small to medium size projects (<1000 input files) the default value is
# probably good enough. For larger projects a too small cache size can cause
# doxygen to be busy swapping symbols to and from disk most of the time
# causing a significant performance penality.
# If the system has enough physical memory increasing the cache will improve the
# performance by keeping more symbols in memory. Note that the value works on
# a logarithmic scale so increasing the size by one will rougly double the
# memory usage. The cache size is given by this formula:
DynGig-Util
view release on metacpan or search on metacpan
lib/DynGig/Util/MultiPhase.pm view on Meta::CPAN
=cut
sub run
{
my ( $this, %param ) = @_;
my ( %busy, %retry, %error, %thread );
my $retry = $this->{retry};
my $thread = $this->{thread};
my %dst = %{ $this->{dst} };
my %src = %{ $this->{src} };
my $queue = Thread::Queue->new();
lib/DynGig/Util/MultiPhase.pm view on Meta::CPAN
{
$retry{$dst} ||= 0;
if ( $retry{$dst} < $retry )
{
$dst{$dst} = $busy{$dst};
$retry{$dst} ++;
}
else
{
$error{$dst} = $result;
}
}
else
{
$src{$dst} = $busy{$dst};
}
$src{$src} = $busy{$src};
delete $busy{$src};
delete $busy{$dst};
$thread{$src}{$dst}->join();
print $handle "$src => $dst $result";
}
lib/DynGig/Util/MultiPhase.pm view on Meta::CPAN
{
last unless keys %src && keys %dst;
my ( $src, $dst ) = $this->_select( \%src, \%dst );
$busy{$src} = $src{$src};
$busy{$dst} = $dst{$dst};
delete $src{$src};
delete $dst{$dst};
$thread{$src}{$dst} = threads::async
EAFDSS
view release on metacpan or search on metacpan
lib/EAFDSS.pm view on Meta::CPAN
0x09: Printing type bad
0x0A: Cannot execute with day open
0x0B: RTC programming requires jumper
0x0C: RTC date or time invalid
0x0D: No records in fiscal period
0x0E: Device is busy in another task
0x0F: No more header records allowed
0x10: Cannot execute with block open
0x11: Block not open
0x12: Bad data stream
0x13: Bad signature field
EBook-Generator
view release on metacpan or search on metacpan
./website2ebook.pl http://secrethistoryofstarwars.com/
./website2ebook.pl http://www.paulgraham.com/13sentences.html
./website2ebook.pl http://rigaux.org/language-study/syntax-across-languages.html
./website2ebook.pl http://www.math.tamu.edu/~cyan/Rota/mitless.html
./website2ebook.pl http://designmatrix.wordpress.com/2009/08/12/10-signs-of-intellectual-honesty-3/
./website2ebook.pl http://zenhabits.net/the-essential-time-saving-guide-for-busy-people/
./website2ebook.pl http://pewresearch.org/pubs/1623/future-cloud-computing-technology-experts
./website2ebook.pl http://www.wilshipley.com/blog/2008/07/pimp-my-code-part-15-greatest-bug-of.html
./website2ebook.pl http://blog.wolfram.com/2008/12/01/the-incredible-convenience-of-mathematica-image-processing/
./website2ebook.pl http://www.dirjournal.com/info/most-dangerous-roads-in-the-world/
./website2ebook.pl http://zenhabits.net/the-only-guide-to-happiness-youll-ever-need/
EBook-Tools
view release on metacpan or search on metacpan
t/test-part1.html
t/test-part2.html
t/test-containsmetadata.html
t/testopf-emptyuid.xml
t/testopf-missingfwid.xml
t/toobusy.jpg
t/imp/README.txt
t/imp/REBtestdoc-ETI.RES/BEDO
t/imp/REBtestdoc-ETI.RES/BYVI
t/imp/REBtestdoc-ETI.RES/DATA.FRK
t/imp/REBtestdoc-ETI.RES/DCXK
EOL
view release on metacpan or search on metacpan
t/dracula.DOS.txt view on Meta::CPAN
where a man could hide. Men much relieved when search over, and
went back to work cheerfully. First mate scowled, but said
nothing.
22 July.--Rough weather last three days, and all hands busy
with sails, no time to be frightened. Men seem to have
forgotten their dread. Mate cheerful again, and all on
good terms. Praised men for work in bad weather. Passed
Gibraltar and out through Straits. All well.
t/dracula.DOS.txt view on Meta::CPAN
bad enough to lose, and if they delayed they would sacrifice Miss
Lucy. So, sobbing and crying they went about their way, half clad as
they were, and prepared fire and water. Fortunately, the kitchen and
boiler fires were still alive, and there was no lack of hot water. We
got a bath and carried Lucy out as she was and placed her in it.
Whilst we were busy chafing her limbs there was a knock at the hall
door. One of the maids ran off, hurried on some more clothes, and
opened it. Then she returned and whispered to us that there was a
gentleman who had come with a message from Mr. Holmwood. I bade her
simply tell him that he must wait, for we could see no one now. She
went away with the message, and, engrossed with our work, I clean
t/dracula.DOS.txt view on Meta::CPAN
from both my bedroom and the drawing room I can see the
great elms of the cathedral close, with their great black
stems standing out against the old yellow stone of the cathedral,
and I can hear the rooks overhead cawing and cawing and
chattering and chattering and gossiping all day, after the manner
of rooks--and humans. I am busy, I need not tell you, arranging
things and housekeeping. Jonathan and Mr. Hawkins are busy all
day, for now that Jonathan is a partner, Mr. Hawkins wants to
tell him all about the clients.
"How is your dear mother getting on? I wish I could run up
to town for a day or two to see you, dear, but I dare not
t/dracula.DOS.txt view on Meta::CPAN
cargo of the Count's to its place in London. Later, we may be able to
deal with it. Billington junior, a nice lad, met me at the station,
and brought me to his father's house, where they had decided that I
must spend the night. They are hospitable, with true Yorkshire
hospitality, give a guest everything and leave him to do as he likes.
They all knew that I was busy, and that my stay was short, and Mr.
Billington had ready in his office all the papers concerning the
consignment of boxes. It gave me almost a turn to see again one of
the letters which I had seen on the Count's table before I knew of his
diabolical plans. Everything had been carefully thought out, and done
systematically and with precision. He seemed to have been prepared
t/dracula.DOS.txt view on Meta::CPAN
took ill, and Quincey is more like his own bright self than he has
been for many a long day.
Van Helsing stepped from the carriage with the eager nimbleness of a
boy. He saw me at once, and rushed up to me, saying, "Ah, friend
John, how goes all? Well? So! I have been busy, for I come here to
stay if need be. All affairs are settled with me, and I have much to
tell. Madam Mina is with you? Yes. And her so fine husband? And
Arthur and my friend Quincey, they are with you, too? Good!"
As I drove to the house I told him of what had passed, and of how my
t/dracula.DOS.txt view on Meta::CPAN
1 October, 4 A.M.--Just as we were about to leave the house, an urgent
message was brought to me from Renfield to know if I would see him at
once, as he had something of the utmost importance to say to me. I
told the messenger to say that I would attend to his wishes in the
morning, I was busy just at the moment.
The attendant added, "He seems very importunate, sir. I have never
seen him so eager. I don't know but what, if you don't see him soon,
he will have one of his violent fits." I knew the man would not have
said this without some cause, so I said, "All right, I'll go now," and
t/dracula.DOS.txt view on Meta::CPAN
speak of anything that has happened. I rest on the sofa, so as not to
disturb her.
1 October, later.--I suppose it was natural that we should have all
overslept ourselves, for the day was a busy one, and the night had no
rest at all. Even Mina must have felt its exhaustion, for though I
slept till the sun was high, I was awake before her, and had to call
two or three times before she awoke. Indeed, she was so sound asleep
that for a few seconds she did not recognize me, but looked at me with
a sort of blank terror, as one looks who has been waked out of a bad
ETLp
view release on metacpan or search on metacpan
lib/ETLp/Manual/Install.pod view on Meta::CPAN
4. Perform the user request
5. Exit
=back
With small applications on a non-busy site, this shouldn't cause any issues. However, it doesn't scale very well. Although ETLp Runtime Audit Browser isn't especially busy, it does requite many dependent classes. In order to mitigate the issues abov...
=over 4
1. When the first request is received, the Persistent Perl interpreter is launched.
2. The code is compiled and a connection is made to the database.
EV-Loop-Async
view release on metacpan or search on metacpan
=head1 DESCRIPTION
This module implements a rather specialised event loop - it takes a normal
L<EV> event loop and runs it in a separate thread. That means it will poll
for events even while your foreground Perl interpreter is busy (you don't
need to have perls pseudo-threads enabled for this either).
Whenever the event loop detecs new events, it will interrupt perl and ask
it to invoke all the pending watcher callbacks. This invocation will be
"synchronous" (in the perl thread), but it can happen at any time.
instantaneous, or take a few hours).
No locking is required.
Example: lock the loop, create a timer, nudge the loop so it takes notice
of the new timer, then evily busy-wait till the timer fires.
my $timer;
my $flag;
{
EV-Pg
view release on metacpan or search on metacpan
handle_conn_loss(self);
return;
}
/* ce == 0: END queued, flush pending; ce > 0: END sent.
* asyncStatus is already PGASYNC_BUSY — fall through to
* drain COMMAND_OK (or set draining_single_row if busy). */
check_flush(self);
if (self->magic != EV_PG_MAGIC || !self->conn) {
if (last_res) PQclear(last_res);
return;
}
EV
view release on metacpan or search on metacpan
libev/ev.pod view on Meta::CPAN
but if that fails, expect a fairly low limit on the number of fds when
using this backend. It doesn't scale too well (O(highest_fd)), but its
usually the fastest backend for a low number of (low-numbered :) fds.
To get good performance out of this backend you need a high amount of
parallelism (most of the file descriptors should be busy). If you are
writing a server, you should C<accept ()> in a loop to accept as many
connections as possible during one iteration. You might also want to have
a look at C<ev_set_io_collect_interval ()> to increase the amount of
readiness notifications you get per iteration.
libev/ev.pod view on Meta::CPAN
one cannot even remove them from the set) than registered in the set
(especially on SMP systems). Libev tries to counter these spurious
notifications by employing an additional generation counter and comparing
that against the events to filter out spurious ones, recreating the set
when required. Epoll also erroneously rounds down timeouts, but gives you
no way to know when and by how much, so sometimes you have to busy-wait
because epoll returns immediately despite a nonzero timeout. And last
not least, it also refuses to work with some file descriptors which work
perfectly fine with C<select> (files, many character devices...).
Epoll is truly the train wreck among event poll mechanisms, a frankenpoll,
libev/ev.pod view on Meta::CPAN
feature-first, correctness-later approach, and is slower than epoll, so
it is not used by default.
One important misdesign is that when sleeping in io_uring, the kernel
wrongly counts that as disk I/O wait, keeping loadavg and a cpu core
"virtually" busy, even if nothing actually waits for disk or uses CPU.
If your application forks frequently, then this backend might be faster,
as setting it up again after a fork is far more efficient with this
backend, and it also doesn't suffer from the epoll design flaw of
receiving events for closed file descriptors.
libev/ev.pod view on Meta::CPAN
to spend more time collecting timeouts, at the expense of increased
latency/jitter/inexactness (the watcher callback will be called
later). C<ev_io> watchers will not be affected. Setting this to a non-null
value will not introduce any overhead in libev.
Many (busy) programs can usually benefit by setting the I/O collect
interval to a value near C<0.1> or so, which is often enough for
interactive servers (of course not for games), likewise for timeouts. It
usually doesn't make much sense to set it to a lower value than C<0.01>,
as this approaches the timing granularity of most systems. Note that if
you do transactions with the outside world and you can't increase the
libev/ev.pod view on Meta::CPAN
situation, and no known thread-safe method of removing the connection to
cope with overload is known (to me).
One of the easiest ways to handle this situation is to just ignore it
- when the program encounters an overload, it will just loop until the
situation is over. While this is a form of busy waiting, no OS offers an
event-based way to handle this situation, so it's the best one can do.
A better way to handle the situation is to log any errors other than
C<EAGAIN> and C<EWOULDBLOCK>, making sure not to flood the log with such
messages, and continue as usual, which at least gives the user an idea of
libev/ev.pod view on Meta::CPAN
Libev doesn't normally do any kind of I/O itself, and so is not blocking
the process. The exception are C<ev_stat> watchers - those call C<stat
()>, which is a synchronous operation.
For local paths, this usually doesn't matter: unless the system is very
busy or the intervals between stat's are large, a stat call will be fast,
as the path data is usually in memory already (except when starting the
watcher).
For networked file systems, calling C<stat ()> can block an indefinite
time due to network issues, and even under good conditions, a stat call
libev/ev.pod view on Meta::CPAN
Idle watchers trigger events when no other events of the same or higher
priority are pending (prepare, check and other idle watchers do not count
as receiving "events").
That is, as long as your process is busy handling sockets or timeouts
(or even signals, imagine) of the same or higher priority it will not be
triggered. But when your process is idle (or only lower-priority watchers
are pending), the idle watchers are being called once per event loop
iteration - until stopped, that is, or your process receives more events
and becomes busy again with higher priority stuff.
The most noteworthy effect is that as long as any idle watchers are
active, the process will not block when waiting for new events.
Apart from keeping your process non-blocking (which is a useful
EWS-Calendar-Viewer
view release on metacpan or search on metacpan
lib/EWS/Calendar/Viewer.pm view on Meta::CPAN
=head1 CONFIGURATION
=head2 privacy_level
This can be set to C<public> to show only your free/busy status, C<limited> to
show the title of the event as well, or C<private> to show all details of the
event in a tooltip.
=head2 start_of_week
EWS-Client
view release on metacpan or search on metacpan
lib/EWS/Calendar/Role/Reader.pm view on Meta::CPAN
with 'EWS::Calendar::Role::RetrieveWithinWindow','EWS::Calendar::Role::RetrieveAvailability';
use EWS::Calendar::Window;
sub retrieve {
my ($self, $opts) = @_;
if($opts->{'freebusy'}){
return $self->retrieve_availability({
window => EWS::Calendar::Window->new($opts),
%$opts,
});
} else {
EekBoek
view release on metacpan or search on metacpan
lib/EB/DB.pm view on Meta::CPAN
my ($self) = @_;
$self->connectdb;
$self->adm("bky") ne BKY_PREVIOUS;
}
sub adm_busy {
my ($self) = @_;
$self->connectdb;
$self->do("SELECT COUNT(*) FROM Journal")->[0];
}
Eixo-Docker
view release on metacpan or search on metacpan
=head2 Interacting with images
=head3 Getting an image
## get
my $image = $a->images->get(id => "busybox");
=head3 Getting an image history
## history
=head3 Create an image pulling it from registry
## create
my $image = $a->images->create(
fromImage=>'busybox',
onSuccess=>sub {
print "FINISHED\n";
Ekahau
view release on metacpan or search on metacpan
Ekahau/Response/Error.pm view on Meta::CPAN
-1001 => ['CONTEXT_NOT_FOUND','Location Context Not Found','No location context exists for the requested context ID'],
1 => ['MALFORMED_REQUEST','Malformed Request','The Ekahau engine expected HELLO and TALK commands but received something else.'],
2 => ['AUTHENTICATION_FAILED','Authentication Failed','Password or license is wrong.'],
3 => ['UNSUPPORTED_PROTOCOL','Unsupported protocol','The requested protocol was not found.'],
4 => ['LICENSE_VIOLATION','License Violation','Too many open sockets for your license.'],
5 => ['ACCESS_DENIED','Access Denied','Authentication was OK, but the connect was refused either because your IP address is not allowed to connect, or because the server is too busy.'],
6 => ['AUTH_TIMEOUT','Authentication timeout','HELLO and TALK commands were not sent quickly enough'],
);
# Internal method
sub init
Ekahau/Response/Error.pm view on Meta::CPAN
=head3 EKAHAU_ERR_ACCESS_DENIED
Access Denied. Authentication was OK, but the connect was refused
either because your IP address is not allowed to connect, or because
the server is too busy.
=head3 EKAHAU_ERR_CONSUMER_NOT_RESPONDING
Consumer Not Responding. The device which you are trying to track
might not be responding. Check that the device is still connected to
Embedix-DB
view release on metacpan or search on metacpan
my $apache_ecd = Embedix::ECD->newFromFile('apache.ecd');
$edb->updateDistro(ecd => $apache_ecd);
deleting components from a distro
$edb->deleteNode(name => 'busybox');
=head1 REQUIRES
=over 4
Embedix-ECD
view release on metacpan or search on metacpan
=head1 SYNOPSIS
instantiate from a file
my $ecd = Embedix::ECD->newFromFile('busybox.ecd');
my $other_ecd = Embedix::ECD->newFromFile('tinylogin.ecd');
access nodes
my $busybox = $ecd->System->Utilities->busybox;
build from scratch
my $server = Embedix::ECD::Group->new(name => 'Server');
my $www = Embedix::ECD::Group->new(name => 'WWW');
$ecd->Server->addChild($www);
$ecd->Server->WWW->addChild($apache);
get/set attributes
my $srpm = $busybox->srpm();
$busybox->help('i am busybox of borg -- unix will be assimilated.');
$busybox->requires([
'libc.so.6',
'ld-linux.so.2',
'skellinux',
]);
parameters which represent the attributes the object should have. The
set of valid attributes is described under L</Attributes>.
$system = Embedix::ECD::Group->new(name => 'System');
$utilities = Embedix::ECD::Group->new(name => 'Utilities');
$busybox = Embedix::ECD::Component->new(
name => 'busybox',
type => 'bool',
value => 0,
srpm => 'busybox',
static_size => 3006,
min_dynamic_size=> 0,
storage_size => 4408,
startup_time => 0,
keeplist => [ '/bin/busybox' ],
requires_expr => [
'(libc.so.6 == "y") &&',
'(ld-linux.so.2 == "y") &&',
'(skellinux == "y") &&',
'( (Misc-utilities == "y")',
C<n()> is an alias for C<getChild()>. "n" stands for "node" and is a
lot easier to type than "getChild".
$ecd->n('System')
->n('Utilities')
->n('busybox')
->n('long-ass-option-name-with-redundant-information');
=item addChild($obj)
This adds a child to the current node.
=head2 Accessing Child Nodes via AUTOLOAD
The name of a node can be used as a method. This is what makes it
possible to say something like:
my $busybox = $ecd->System->Utilities->busybox;
and get back the Embedix::ECD::Component object that contains the
information for the busybox package. "System", "Utilities", and
"busybox" are not predefined methods in Embedix::ECD or any of its
subclasses, so they are delegated to the AUTOLOAD method. The AUTOLOAD
method will try to find a child with the same name as the undefined
method and it will return it if found.
I have not yet decided whether the AUTOLOAD should die when a child is
attributes are non-reference scalar values, and aggregate attributes are
non-reference scalar values enclosed within an arrayref.
A single valued attribute:
my $bbsed = $busybox->n('Misc-utilities')->n('keep-bb-sed');
$bbsed->provides('sed');
The same attribute as an aggregate:
$bbsed->provides([ 'sed' ]);
Again, these two expressions mean the same thing. An aggregate of one
is interpreted just as if it were a single value.
Aggregates become useful when attributes needs to have a list of values.
$busybox->n('compile-time-features')->n('enable-bb-feature-use-inittab')->requires ([
'keep-bb-init',
'inittab',
'/bin/sh',
]);
behaves as a setter and the value of the parameter is assigned to the
attribute.
getter:
my $name = $busybox->name();
setter:
$busybox->name('busybox');
=head2 Accessors For Single-Valued Attributes
These are accessors for attributes that are typically single-valued.
=item specpatch
This attribute is only meaningful within the context of a component.
Specpatches are applied to .spec files just prior to the building of a
component. They are often used to configure the compilation of a
component. The busybox package provides a good example of this in
action.
$ecd->specpatch()
=item static_size
$ecd->build_vars()
=item provides
This is a list of symbolic names that a node is said to be able to
provide. For example, grep in busybox provides grep. GNU/grep also
provides grep. According to TargetWizard, these two cannot coexist on
the same instance of an Embedix distribution, because they both provide
grep.
$ecd->provides()
=back
=head1 BUGS
This parser becomes exponentially slower as the size of ECD data
increases. busybox.ecd takes 30 seconds to parse.
Don't even try to parse linux.ecd -- it will sit there for hours
just sucking CPU before it ultimately fails and gives you back
nothing. I don't know if there's anything I can do about it.
I have noticed that XML::Parser (which wraps around the C library,
expat) is 60 times faster than my Parse::RecDescent-based parser
when reading busybox.ecd. I really want to take advantage of this.
=head1 COPYRIGHT
Copyright (c) 2000,2001 John BEPPU. All rights reserved. This program is
free software; you can redistribute it and/or modify it under the same
Event
view release on metacpan or search on metacpan
lib/Event.pod view on Meta::CPAN
Watchers are returned in order of most recent to least recent.
=item all_idle()
Returns a list of all the idle watchers.
If the event queue is very busy, all the idle watchers will sit on the
idle queue waiting to run. However, be aware that if an idle watcher
has the C<max> attribute set then it will queue a normal event when
its C<max> wait time is exceeded.
=item queue_pending()
ExtUtils-MakeMaker-BigHelper
view release on metacpan or search on metacpan
lib/ExtUtils/MakeMaker/BigHelper.pm view on Meta::CPAN
# For example in AIX the shared objects/libraries from previous builds
# linger quite a while in the shared dynalinker cache even when nobody
# is using them. This is painful if one for instance tries to restart
# a failed build because the link command will fail unnecessarily 'cos
# the shared object/library is 'busy'.
push(@m,' $(RM_F) $@
');
my $libs = '$(LDLOADLIBS)';
ExtUtils-MakeMaker
view release on metacpan or search on metacpan
lib/ExtUtils/MM_OS390.pm view on Meta::CPAN
# For example in AIX the shared objects/libraries from previous builds
# linger quite a while in the shared dynalinker cache even when nobody
# is using them. This is painful if one for instance tries to restart
# a failed build because the link command will fail unnecessarily 'cos
# the shared object/library is 'busy'.
push(@m," \$(RM_F) \$\@\n");
my $libs = '$(LDLOADLIBS)';
my $ld_run_path_shell = "";
FAQ-OMatic
view release on metacpan or search on metacpan
lib/FAQ/OMatic.pm view on Meta::CPAN
my $uptime = `uptime`;
$uptime =~ m/load average: ([\d\.]+)/;
my $load = $1;
if ($load > 4) {
FAQ::OMatic::gripe('abort',
"I'm too busy for that now. (I'm kind of a crummy PC.)");
}
}
# Return the integer prefix to this string, or 0.
# Used to fix "argument isn't numeric" warnings.
FCGI-Spawn
view release on metacpan or search on metacpan
lib/FCGI/Spawn.pm view on Meta::CPAN
With mod_fcgid, the compiled Perl code is not being shared among forks by far.
=item * Too much need for root
The startup.pl providing the memory sharing among forks is aimed to be run as root, at least when you need to listen binded to ports numbered less than 1024, for example, 80.
And, the root user ( the human ) is often too busy to check if that massive code is secure enough to be run as root system user ( the effective UID ) Thus, it's no much deal to accelerate Perl on mod_perl steroids if the startup.pl includes rather sm...
Root is needed to recompile the Perl sources, at least with the useful Registry handler.
It is obvious to gracefully restart Apache once per N minutes and this is what several hosting panel use to do but it is not convinient to debug code that is migrated from developer's hosting to production's as it is needed to be recompiled on webma...
And, with no ( often proprietary ) hosting panel software onboard, Apache doesn't even gracefully restart on a regular basis without special admin care taken at server setup time.
On the uptime had gone till the need of restart after launch it is not an admin favor to do this, even gracefully.
FCGI
view release on metacpan or search on metacpan
* a drop-dead timer. Its only used for AF_UNIX sockets (not TCP sockets).
* Its a workaround for a kernel bug in Linux 2.0.x and SCO Unixware.
* Making this as small as possible, yet remain reliable would be best.
* 2 seconds is very conservative. 0,0 is not reliable. The shorter the
* timeout, the faster request processing will recover. The longer the
* timeout, the more likely this application being "busy" will cause other
* requests to abort and cause more dead sockets that need this timeout. */
#define READABLE_UNIX_FD_DROP_DEAD_TIMEVAL 2,0
#ifndef STDIN_FILENO
#define STDIN_FILENO 0
FFI-Raw
view release on metacpan or search on metacpan
deps/libffi/install-sh view on Meta::CPAN
# to itself, or perhaps because mv is so ancient that it does not
# support -f.
{
# Now remove or move aside any old file at destination location.
# We try this two ways since rm can't unlink itself on some
# systems and the destination file might be busy for other
# reasons. In this case, the final cleanup might fail but the new
# file should still install successfully.
{
test ! -f "$dst" ||
$doit $rmcmd -f "$dst" 2>/dev/null ||
( run in 2.403 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )