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
Event.pm 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
"c/queue.c"

Help or pointers to info would be appreciated.

Hi,

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
$client->{free}).

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).

Hi!

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
benchmarks.

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

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

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
Glib.

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

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
considerably.

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
distro:

- EV::ADNS

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

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.

Can you retry with a more recent version? Even perl 5.6 is really old by
now. My development box has 5.8.8.

Hi!

EV version 1.5 is now out.

Documentation for the perl module: http://cvs.schmorp.de/EV/README
Documentation for libev library: http://cvs.schmorp.de/libev/ev.html

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...

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.
...