| … | |
… | |
| 5 | =head1 Introduction to AnyEvent |
5 | =head1 Introduction to AnyEvent |
| 6 | |
6 | |
| 7 | This is a tutorial that will introduce you to the features of AnyEvent. |
7 | This is a tutorial that will introduce you to the features of AnyEvent. |
| 8 | |
8 | |
| 9 | The first part introduces the core AnyEvent module (after swamping you a |
9 | The first part introduces the core AnyEvent module (after swamping you a |
| 10 | bit in evangelism), which might already provide all you ever need. If you |
10 | bit in evangelism), which might already provide all you ever need: If you |
| 11 | are only interested in AnyEvent's event handling capabilities, read no |
11 | are only interested in AnyEvent's event handling capabilities, read no |
| 12 | further. |
12 | further. |
| 13 | |
13 | |
| 14 | The second part focuses on network programming using sockets, for which |
14 | The second part focuses on network programming using sockets, for which |
| 15 | AnyEvent offers a lot of support you can use, and a lot of workarounds |
15 | AnyEvent offers a lot of support you can use, and a lot of workarounds |
| … | |
… | |
| 23 | AnyEvent is first of all just a framework to do event-based |
23 | AnyEvent is first of all just a framework to do event-based |
| 24 | programming. Typically such frameworks are an all-or-nothing thing: If you |
24 | programming. Typically such frameworks are an all-or-nothing thing: If you |
| 25 | use one such framework, you can't (easily, or even at all) use another in |
25 | use one such framework, you can't (easily, or even at all) use another in |
| 26 | the same program. |
26 | the same program. |
| 27 | |
27 | |
| 28 | AnyEvent is different - it is a thin abstraction layer above all kinds |
28 | AnyEvent is different - it is a thin abstraction layer on top of other of |
|
|
29 | event loops, just like DBI is an abstraction of many different database |
| 29 | of event loops. Its main purpose is to move the choice of the underlying |
30 | APIs. Its main purpose is to move the choice of the underlying framework |
| 30 | framework (the event loop) from the module author to the program author |
31 | (the event loop) from the module author to the program author using the |
| 31 | using the module. |
32 | module. |
| 32 | |
33 | |
| 33 | That means you can write code that uses events to control what it |
34 | That means you can write code that uses events to control what it |
| 34 | does, without forcing other code in the same program to use the same |
35 | does, without forcing other code in the same program to use the same |
| 35 | underlying framework as you do - i.e. you can create a Perl module |
36 | underlying framework as you do - i.e. you can create a Perl module |
| 36 | that is event-based using AnyEvent, and users of that module can still |
37 | that is event-based using AnyEvent, and users of that module can still |
| 37 | choose between using L<Gtk2>, L<Tk>, L<Event> or no event loop at |
38 | choose between using L<Gtk2>, L<Tk>, L<Event> (or run inside Irssi or |
| 38 | all: AnyEvent comes with its own event loop implementation, so your |
39 | rxvt-unicode) or any other supported event loop. AnyEvent even comes with |
| 39 | code works regardless of other modules that might or might not be |
40 | its own pure-perl event loop implementation, so your code works regardless |
| 40 | installed. The latter is important, as AnyEvent does not have any |
41 | of other modules that might or might not be installed. The latter is |
| 41 | dependencies to other modules, which makes it easy to install, for |
42 | important, as AnyEvent does not have any hard dependencies to other |
| 42 | example, when you lack a C compiler. |
43 | modules, which makes it easy to install, for example, when you lack a C |
|
|
44 | compiler. No mater what environment, AnyEvent will just cope with it. |
| 43 | |
45 | |
| 44 | A typical problem with Perl modules such as L<Net::IRC> is that they |
46 | A typical limitation of existing Perl modules such as L<Net::IRC> is that |
| 45 | come with their own event loop: In L<Net::IRC>, the program who uses it |
47 | they come with their own event loop: In L<Net::IRC>, the program who uses |
| 46 | needs to start the event loop of L<Net::IRC>. That means that one cannot |
48 | it needs to start the event loop of L<Net::IRC>. That means that one |
| 47 | integrate this module into a L<Gtk2> GUI for instance, as that module, |
49 | cannot integrate this module into a L<Gtk2> GUI for instance, as that |
| 48 | too, enforces the use of its own event loop (namely L<Glib>). |
50 | module, too, enforces the use of its own event loop (namely L<Glib>). |
| 49 | |
51 | |
| 50 | Another example is L<LWP>: it provides no event interface at all. It's a |
52 | Another example is L<LWP>: it provides no event interface at all. It's |
| 51 | pure blocking HTTP (and FTP etc.) client library, which usually means that |
53 | a pure blocking HTTP (and FTP etc.) client library, which usually means |
| 52 | you either have to start a thread or have to fork for a HTTP request, or |
54 | that you either have to start another process or have to fork for a HTTP |
| 53 | use L<Coro::LWP>, if you want to do something else while waiting for the |
55 | request, or use threads (e.g. L<Coro::LWP>), if you want to do something |
| 54 | request to finish. |
56 | else while waiting for the request to finish. |
| 55 | |
57 | |
| 56 | The motivation behind these designs is often that a module doesn't want to |
58 | The motivation behind these designs is often that a module doesn't want |
| 57 | depend on some complicated XS-module (Net::IRC), or that it doesn't want |
59 | to depend on some complicated XS-module (Net::IRC), or that it doesn't |
| 58 | to force the user to use some specific event loop at all (LWP). |
60 | want to force the user to use some specific event loop at all (LWP), out |
|
|
61 | of fear of severly limiting the usefulness of the module: If your module |
|
|
62 | requires Glib, it will not run in a Tk program. |
| 59 | |
63 | |
| 60 | L<AnyEvent> solves this dilemma, by B<not> forcing module authors to either |
64 | L<AnyEvent> solves this dilemma, by B<not> forcing module authors to |
|
|
65 | either: |
| 61 | |
66 | |
| 62 | =over 4 |
67 | =over 4 |
| 63 | |
68 | |
| 64 | =item - write their own event loop (because guarantees to offer one |
69 | =item - write their own event loop (because it guarantees the availability |
| 65 | everywhere - even on windows). |
70 | of an event loop everywhere - even on windows with no extra modules |
|
|
71 | installed). |
| 66 | |
72 | |
| 67 | =item - choose one fixed event loop (because AnyEvent works with all |
73 | =item - choose one specific event loop (because AnyEvent works with most |
| 68 | important event loops available for Perl, and adding others is trivial). |
74 | event loops available for Perl). |
| 69 | |
75 | |
| 70 | =back |
76 | =back |
| 71 | |
77 | |
| 72 | If the module author uses L<AnyEvent> for all his event needs (IO events, |
78 | If the module author uses L<AnyEvent> for all his (or her) event needs |
| 73 | timers, signals, ...) then all other modules can just use his module and |
79 | (IO events, timers, signals, ...) then all other modules can just use |
| 74 | don't have to choose an event loop or adapt to his event loop. The choice |
80 | his module and don't have to choose an event loop or adapt to his event |
| 75 | of the event loop is ultimately made by the program author who uses all |
81 | loop. The choice of the event loop is ultimately made by the program |
| 76 | the modules and writes the main program. And even there he doesn't have to |
82 | author who uses all the modules and writes the main program. And even |
| 77 | choose, he can just let L<AnyEvent> choose the best available event loop |
83 | there he doesn't have to choose, he can just let L<AnyEvent> choose the |
| 78 | for him. |
84 | most efficient event loop available on the system. |
| 79 | |
85 | |
| 80 | Read more about this in the main documentation of the L<AnyEvent> module. |
86 | Read more about this in the main documentation of the L<AnyEvent> module. |
| 81 | |
87 | |
| 82 | |
88 | |
| 83 | =head1 Introduction to Event-Based Programming |
89 | =head1 Introduction to Event-Based Programming |
