Login or Register to Ask a Question and Join Our Community

EPTS Report: Event Processing Reference Architecture Working Group (Slides)

Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News EPTS Report: Event Processing Reference Architecture Working Group (Slides)
# 1  
Old 09-23-2007
EPTS Report: Event Processing Reference Architecture Working Group (Slides)

Tim Bass
Sun, 23 Sep 2007 17:33:26 +0000
The Event Processing Technical Society (EPTS) met in Orlando, Florida, collocated with the Gartner Event Processing Symposium. I reported on the activities of the Event Processing Reference Architecture Working Group (EPRAWG) in this set of slides:
Event Processing Technical Society: Event Processing Reference Architecture Working Group - Roll Call and Open Discussion
The full roll call results of the activities, summarized in the slides above for 2006-2007, may be found in this Google spreadsheet.
Please comment if you have any questions or follow-on comments.

Login or Register to Ask a Question

Previous Thread | Next Thread

1 More Discussions You Might Find Interesting

1. Virtualization and Cloud Computing

EPTS: Proposed Event Processing Definitions, September 20, 2006

Tim Bass 08-20-2008 10:47 PM For interested readers, here are the event processing definitions we provided to the (future) EPTS working group on September 20, 2006, coordinated (edited)*by David Luckham and Roy Schulte; adaptive process management (n.) an element of resource and business... (0 Replies)
Discussion started by: Linux Bot
0 Replies
Login or Register to Ask a Question
AnyEvent::Impl::EventLib(3pm)				User Contributed Perl Documentation			     AnyEvent::Impl::EventLib(3pm)

AnyEvent::Impl::EventLib - AnyEvent adaptor for Event::Lib SYNOPSIS
use AnyEvent; use Event::Lib; # this module gets loaded automatically as required DESCRIPTION
This module provides transparent support for AnyEvent. You don't have to do anything to make Event work with AnyEvent except by loading Event::Lib before creating the first AnyEvent watcher. Note: the AnyEvent author has not found recent releases of Event::Lib to be even remotely working (not even the examples from the manpage or the testsuite work), so this event backend should be avoided (or somebody should step up and maintain it, hint, hint). The Event::Lib module suffers from the same limitations and bugs as libevent, most notably it kills already-installed watchers on a file descriptor and it is unable to support fork. These are not fatal issues, and are worked-around by this module, but the Event::Lib perl module itself has many additional bugs such as taking references to file handles and callbacks instead of making a copy or freeing still- allocated scalars, causing memory corruption and random crashes. Only Tk rivals it in its brokenness. This adaptor module employs the same workaround around the watcher problems as Tk and should therefore be avoided. (This was done for simplicity, one could in theory work around the problems with lower overhead by managing our own watchers). Event::Lib also leaks file handles and memory and tends to just exit on problems. It also doesn't work around the Windows bug of not signalling TCP connection failures. It also doesn't work with many special devices on Linux (/dev/random works, /dev/urandom fails, /dev/tty works, /dev/null fails and so on). Event::Lib does not support idle watchers. They could be emulated using low-priority timers but as the priority range (and availability) is not queryable nor guaranteed, and the default priority is likely the lowest one, this module cannot use them. Avoid Event::Lib if you can. SEE ALSO
AnyEvent, Event::Lib. AUTHOR
Marc Lehmann <schmorp@schmorp.de> http://anyevent.schmorp.de perl v5.14.2 2012-04-08 AnyEvent::Impl::EventLib(3pm)

Featured Tech Videos