| … | |
… | |
| 255 | =head1 FUNCTIONS CONTROLLING THE EVENT LOOP |
255 | =head1 FUNCTIONS CONTROLLING THE EVENT LOOP |
| 256 | |
256 | |
| 257 | An event loop is described by a C<struct ev_loop *>. The library knows two |
257 | An event loop is described by a C<struct ev_loop *>. The library knows two |
| 258 | types of such loops, the I<default> loop, which supports signals and child |
258 | types of such loops, the I<default> loop, which supports signals and child |
| 259 | events, and dynamically created loops which do not. |
259 | events, and dynamically created loops which do not. |
| 260 | |
|
|
| 261 | If you use threads, a common model is to run the default event loop |
|
|
| 262 | in your main thread (or in a separate thread) and for each thread you |
|
|
| 263 | create, you also create another event loop. Libev itself does no locking |
|
|
| 264 | whatsoever, so if you mix calls to the same event loop in different |
|
|
| 265 | threads, make sure you lock (this is usually a bad idea, though, even if |
|
|
| 266 | done correctly, because it's hideous and inefficient). |
|
|
| 267 | |
260 | |
| 268 | =over 4 |
261 | =over 4 |
| 269 | |
262 | |
| 270 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
263 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
| 271 | |
264 | |
| … | |
… | |
| 3067 | |
3060 | |
| 3068 | #include "ev_cpp.h" |
3061 | #include "ev_cpp.h" |
| 3069 | #include "ev.c" |
3062 | #include "ev.c" |
| 3070 | |
3063 | |
| 3071 | |
3064 | |
|
|
3065 | =head1 THREADS AND COROUTINES |
|
|
3066 | |
|
|
3067 | =head2 THREADS |
|
|
3068 | |
|
|
3069 | Libev itself is completely threadsafe, but it uses no locking. This |
|
|
3070 | means that you can use as many loops as you want in parallel, as long as |
|
|
3071 | only one thread ever calls into one libev function with the same loop |
|
|
3072 | parameter. |
|
|
3073 | |
|
|
3074 | Or put differently: calls with different loop parameters can be done in |
|
|
3075 | parallel from multiple threads, calls with the same loop parameter must be |
|
|
3076 | done serially (but can be done from different threads, as long as only one |
|
|
3077 | thread ever is inside a call at any point in time, e.g. by using a mutex |
|
|
3078 | per loop). |
|
|
3079 | |
|
|
3080 | If you want to know which design is best for your problem, then I cannot |
|
|
3081 | help you but by giving some generic advice: |
|
|
3082 | |
|
|
3083 | =over 4 |
|
|
3084 | |
|
|
3085 | =item * most applications have a main thread: use the default libev loop |
|
|
3086 | in that thread, or create a seperate thread running only the default loop. |
|
|
3087 | |
|
|
3088 | This helps integrating other libraries or software modules that use libev |
|
|
3089 | themselves and don't care/know about threading. |
|
|
3090 | |
|
|
3091 | =item * one loop per thread is usually a good model. |
|
|
3092 | |
|
|
3093 | Doing this is almost never wrong, sometimes a better-performance model |
|
|
3094 | exists, but it is always a good start. |
|
|
3095 | |
|
|
3096 | =item * other models exist, such as the leader/follower pattern, where one |
|
|
3097 | loop is handed through multiple threads in a kind of round-robbin fashion. |
|
|
3098 | |
|
|
3099 | Chosing a model is hard - look around, learn, know that usually you cna do |
|
|
3100 | better than you currently do :-) |
|
|
3101 | |
|
|
3102 | =item * often you need to talk to some other thread which blocks in the |
|
|
3103 | event loop - C<ev_async> watchers can be used to wake them up from other |
|
|
3104 | threads safely (or from signal contexts...). |
|
|
3105 | |
|
|
3106 | =back |
|
|
3107 | |
|
|
3108 | =head2 COROUTINES |
|
|
3109 | |
|
|
3110 | Libev is much more accomodating to coroutines ("cooperative threads"): |
|
|
3111 | libev fully supports nesting calls to it's functions from different |
|
|
3112 | coroutines (e.g. you can call C<ev_loop> on the same loop from two |
|
|
3113 | different coroutines and switch freely between both coroutines running the |
|
|
3114 | loop, as long as you don't confuse yourself). The only exception is that |
|
|
3115 | you must not do this from C<ev_periodic> reschedule callbacks. |
|
|
3116 | |
|
|
3117 | Care has been invested into making sure that libev does not keep local |
|
|
3118 | state inside C<ev_loop>, and other calls do not usually allow coroutine |
|
|
3119 | switches. |
|
|
3120 | |
|
|
3121 | |
| 3072 | =head1 COMPLEXITIES |
3122 | =head1 COMPLEXITIES |
| 3073 | |
3123 | |
| 3074 | In this section the complexities of (many of) the algorithms used inside |
3124 | In this section the complexities of (many of) the algorithms used inside |
| 3075 | libev will be explained. For complexity discussions about backends see the |
3125 | libev will be explained. For complexity discussions about backends see the |
| 3076 | documentation for C<ev_default_init>. |
3126 | documentation for C<ev_default_init>. |
