Home FAQ Contact Sign in
perl.loop only
Advanced search
September 2008
1234567 36
891011121314 37
15161718192021 38
22232425262728 39
2930      40
 Jan   Feb   Mar   Apr 
 May   Jun   Jul   Aug 
 Sep   Oct   Nov   Dec 
2008 2007 2006  
perl.loop Profileā€¦



  Run-time failure         

Author: Jeff Boes
Date: Sep 10, 2008 05:40

I'm upgrading an ancient (2004-era) server to the modern era:

2.6.18-92.1.6.el5 x86_64 x86_64 x86_64 GNU/Linux
Perl 5.10 1.1

One of my applications throws the following error once it's been running for a
few minutes as a daemon:

Assertion (((pe_watcher*)wa)->flags & 0x0008) || !wa->running failed: file

Help or pointers to info would be appreciated.

Jeffery Boes <><
[email protected]
no comments
  non blocking issue ?         

Author: Isabelle Cabrera
Date: May 28, 2008 08:48


I have a problem using the Event module.

My goal: I have several sentences that I need to parse. For a faster
process, I have a dispatcher which sends the sentences to several hosts
so that the processes are distributed.

In my dispatcher, I register every host. For each host I create a watcher :

$self->{hosts}{$host}{watcher} =
Event->var(desc =>"Process sentence on $host",
var => \$client->{free},
poll => 'w',
cb => $self->next_dag($host),
debug => 4,

The callback next_dag is called every time all the process of parsing
the sentence and sending back the results is done (more precisely when
the host says it's ready to receive a new sentence, with variable
Show full article (1.85Kb)
  announcing AnyEvent 4.0         

Author: Marc Lehmann
Date: May 24, 2008 11:28

I am pleased to announce AnyEvent 4.0

Why the major version bump?

Lots of functionality has been added (and thus some bugs are expected),
although the event core is still compatible to earlier versions and AnyEvent
is still pure-perl without any (hard) dependencies on any XS modules.

So whats new?

Apart from a number of bugfixes, the AnyEvent::Socket module has been
added. It contains a lot of utility functions to handle IPv4 and IPv6
addresses and tcp connections in a 100%% non-blocking way. It supports SRV
record lookups.

To make the 100%% non-blocking a reality, AnyEvent::Socket uses
AnyEvent::DNS, a fully asynchronous stub resolver capable of making tens
of thousands of DNS requests/second, with TCP and EDNS0 support.

And if you have Net::SSLeay installed, then AnyEvent::Handle can
transparently manage TLS/SSL connections, too.

On the microshit windows side, AnyEvent now tries very hard to avoid
the freeze in the testsuite on broken perls (with reduced functionality,
but resolver and socket code works fine there, too).
Show full article (3.73Kb)
no comments
  benchmarking various event loops with and without anyevent         

Author: Marc Lehmann
Date: Apr 25, 2008 19:46


The next release of AnyEvent contains support for a few more "backends",
notably POE, so AnyEvent is now by definition compatible to POE (before it
was only compatible when using an even loop used by POE, such as Event or
EV that could be shared).

To get a feeling about the overheads imposed by the extra layer of
AnyEvent and especially of the performance of the POE backend (which is
severely limited by a number of design problems in POE), I made some

I started with benchmarking watcher creation/destruction time and callback
invocation time.

The results were mostly as expected, with EV leading and POE being

The surprising one was the pure perl implementation, which was quite on
par with C-based event loops such as Event or Glib. I did expect the pure
perl implementatioon to be at least a factor of three slower than Event or
Show full article (2.94Kb)
  EV module questions         

Author: Peter Maynard
Date: Feb 1, 2008 17:47

Using EV for a daemon re-write and have run into a little trouble.

Original daemon redirected STDERR to a variable $stderr and each time
through the daemon's while loop, I simply checked if the variable had
data and wrote it to syslog as an error if it did. Then I'd clear the
variable and carry on.

I'm now trying to re-create this using EV and I'm having problemss.

NOTE: I can't write the output to a file and watch the file. Due to
operational restrictions, STDERR must go directly to syslog.

I've managed to setup a periodic watcher to write the $stderr variable
to syslog, but it won't clear. I also tried to setup a watcher directly
on STDERR, but that didn't seem to work at all.

Any suggestions or help would be greatly appreciated.

PS. Thanks for EV and Net::SNMP::EV. I was fighting to do this with
POE and EV has been a life saver!

Peter Maynard
no comments
  overview over the EV module family         

Author: Marc Lehmann
Date: Dec 30, 2007 17:16

It's been a while since I announced EV, and in the meantime, not only
has EV proven itself in a lot of apps, the module family around it grew

With version 2.0, EV gained support for multiple event loops and embed
watchers (a bit scarcely documented), so one can now use e.g. kqueue for
sockets only and poll for overall event polling.

A number of new modules are now available, separately from the main EV


This is an interface to libadns, an asynchronous dns resolver library,
that replaces EV::DNS which was removed from EV. It is written in C
and is a nice example on how to access EV from the C level, and how to
effectively integrate foreign event loop users (such as libadns).

- Net::SNMP::EV

This is an adaptor that makes non-blocking Net::SNMP requests run as
part of the EV event loop. It is written fully in Perl and has no public
interface, just loading it makes Net::SNMP requests use EV. This is a nice
example on how to integrate a foreign event loop user using perl only.

- EV::Glib
Show full article (2.92Kb)
no comments
  Re: FAIL Event-1.09 i686-linux 2.4.20-8smp         

Author: Joshua N Pritikin
Date: Dec 6, 2007 06:15

On Thu, Dec 06, 2007 at 12:35:12PM +0200, Alexandr Ciornii wrote:

Oh, that helps. All these failures occurred with perl 5.5.5. That's a
really old version.
> In general all testing errors are shown here:

Can you retry with a more recent version? Even perl 5.6 is really old by
now. My development box has 5.8.8.
no comments
  Re: Replacement of Event with EV         

Author: Uri Guttman
Date: Dec 5, 2007 18:50

>>>>> "ML" == Marc Lehmann writes:
ML> Its a design decision. Combining timers with io watchers is unnatural,
ML> because:
ML> - you often don't need both, so shouldn't be forced to pay for them
ML> - you can't choose the type of timeout (event only has absolute timers
ML> anyways, though, which are unsuitable for many tasks such as idle timeouts
ML> for i/o, where you need relative timeouts).
ML> - you have to manage two timeouts or weirder stuff when you have
ML> two separate i/o watchers, or use a third watcher (paying even more).
ML> - it is often unclear on which events exactly the timeout gets reset
ML> (if at all), and even if not, there is no flexibility (how do you
ML> chose between an idle timeout and an overall timeout
ML> for completion with Event? you cannot).
ML> As it is trivial to create a separate timeout (and much faster than with
ML> Event, too), there is no drawback to this design.
Show full article (1.73Kb)
no comments
  announcing EV 1.5         

Author: Marc Lehmann
Date: Nov 29, 2007 12:03


EV version 1.5 is now out.

Documentation for the perl module:
Documentation for libev library:

The highlights of this release are:

- a new watcher type "EV::fork" has been created that triggers on forks
in the child process.
- a new watcher type "EV::stat" has been created that can be used to track
attribute changes on a filesystem...
Show full article (1.84Kb)
no comments
  Re: announcing the new EV module, a modern redesign of Event         

Author: Jochen Stenzel
Date: Nov 24, 2007 07:53

Hi Marc,

thank you for EV and your detailed intro. I think it's great that you
are engaged in the improvement of event loops as you have a detailed
knowledge of related libraries and system calls and a great experience
in using the various loops. Although I did not have too many problems
with Event and really like to use it, I think it's very worth to have a
look at EV, too.

As I am curious I just started to play with EV. I think I just scratched
its surface, but nevertheles possibly my first impressions might be helpful.

* I think it's great to have Windows support from the beginning, so
programs using EV can be expected to be portable between UNIX and
Windows, similar to the current version of Event.
Show full article (3.43Kb)
1 2 3