| … | |
… | |
| 116 | called C<ev_tstamp>, which is what you should use too. It usually aliases |
116 | called C<ev_tstamp>, which is what you should use too. It usually aliases |
| 117 | to the C<double> type in C, and when you need to do any calculations on |
117 | to the C<double> type in C, and when you need to do any calculations on |
| 118 | it, you should treat it as some floatingpoint value. Unlike the name |
118 | it, you should treat it as some floatingpoint value. Unlike the name |
| 119 | component C<stamp> might indicate, it is also used for time differences |
119 | component C<stamp> might indicate, it is also used for time differences |
| 120 | throughout libev. |
120 | throughout libev. |
|
|
121 | |
|
|
122 | =head1 ERROR HANDLING |
|
|
123 | |
|
|
124 | Libev knows three classes of errors: operating system errors, usage errors |
|
|
125 | and internal errors (bugs). |
|
|
126 | |
|
|
127 | When libev catches an operating system error it cannot handle (for example |
|
|
128 | a syscall indicating a condition libev cannot fix), it calls the callback |
|
|
129 | set via C<ev_set_syserr_cb>, which is supposed to fix the problem or |
|
|
130 | abort. The default is to print a diagnostic message and to call C<abort |
|
|
131 | ()>. |
|
|
132 | |
|
|
133 | When libev detects a usage error such as a negative timer interval, then |
|
|
134 | it will print a diagnostic message and abort (via the C<assert> mechanism, |
|
|
135 | so C<NDEBUG> will disable this checking): these are programming errors in |
|
|
136 | the libev caller and need to be fixed there. |
|
|
137 | |
|
|
138 | Libev also has a few internal error-checking C<assert>ions, and also has |
|
|
139 | extensive consistency checking code. These do not trigger under normal |
|
|
140 | circumstances, as they indicate either a bug in libev or worse. |
|
|
141 | |
| 121 | |
142 | |
| 122 | =head1 GLOBAL FUNCTIONS |
143 | =head1 GLOBAL FUNCTIONS |
| 123 | |
144 | |
| 124 | These functions can be called anytime, even before initialising the |
145 | These functions can be called anytime, even before initialising the |
| 125 | library in any way. |
146 | library in any way. |
| … | |
… | |
| 3293 | |
3314 | |
| 3294 | =over 4 |
3315 | =over 4 |
| 3295 | |
3316 | |
| 3296 | =item The winsocket select function |
3317 | =item The winsocket select function |
| 3297 | |
3318 | |
| 3298 | The winsocket C<select> function doesn't follow POSIX in that it requires |
3319 | The winsocket C<select> function doesn't follow POSIX in that it |
| 3299 | socket I<handles> and not socket I<file descriptors>. This makes select |
3320 | requires socket I<handles> and not socket I<file descriptors> (it is |
| 3300 | very inefficient, and also requires a mapping from file descriptors |
3321 | also extremely buggy). This makes select very inefficient, and also |
| 3301 | to socket handles. See the discussion of the C<EV_SELECT_USE_FD_SET>, |
3322 | requires a mapping from file descriptors to socket handles. See the |
| 3302 | C<EV_SELECT_IS_WINSOCKET> and C<EV_FD_TO_WIN32_HANDLE> preprocessor |
3323 | discussion of the C<EV_SELECT_USE_FD_SET>, C<EV_SELECT_IS_WINSOCKET> and |
| 3303 | symbols for more info. |
3324 | C<EV_FD_TO_WIN32_HANDLE> preprocessor symbols for more info. |
| 3304 | |
3325 | |
| 3305 | The configuration for a "naked" win32 using the microsoft runtime |
3326 | The configuration for a "naked" win32 using the microsoft runtime |
| 3306 | libraries and raw winsocket select is: |
3327 | libraries and raw winsocket select is: |
| 3307 | |
3328 | |
| 3308 | #define EV_USE_SELECT 1 |
3329 | #define EV_USE_SELECT 1 |
| … | |
… | |
| 3386 | =back |
3407 | =back |
| 3387 | |
3408 | |
| 3388 | If you know of other additional requirements drop me a note. |
3409 | If you know of other additional requirements drop me a note. |
| 3389 | |
3410 | |
| 3390 | |
3411 | |
|
|
3412 | =head1 COMPILER WARNINGS |
|
|
3413 | |
|
|
3414 | Depending on your compiler and compiler settings, you might get no or a |
|
|
3415 | lot of warnings when compiling libev code. Some people are apparently |
|
|
3416 | scared by this. |
|
|
3417 | |
|
|
3418 | However, these are unavoidable for many reasons. For one, each compiler |
|
|
3419 | has different warnings, and each user has different tastes regarding |
|
|
3420 | warning options. "Warn-free" code therefore cannot be a goal except when |
|
|
3421 | targetting a specific compiler and compiler-version. |
|
|
3422 | |
|
|
3423 | Another reason is that some compiler warnings require elaborate |
|
|
3424 | workarounds, or other changes to the code that make it less clear and less |
|
|
3425 | maintainable. |
|
|
3426 | |
|
|
3427 | And of course, some compiler warnings are just plain stupid, or simply |
|
|
3428 | wrong (because they don't actually warn about the cindition their message |
|
|
3429 | seems to warn about). |
|
|
3430 | |
|
|
3431 | While libev is written to generate as few warnings as possible, |
|
|
3432 | "warn-free" code is not a goal, and it is recommended not to build libev |
|
|
3433 | with any compiler warnings enabled unless you are prepared to cope with |
|
|
3434 | them (e.g. by ignoring them). Remember that warnings are just that: |
|
|
3435 | warnings, not errors, or proof of bugs. |
|
|
3436 | |
|
|
3437 | |
| 3391 | =head1 VALGRIND |
3438 | =head1 VALGRIND |
| 3392 | |
3439 | |
| 3393 | Valgrind has a special section here because it is a popular tool that is |
3440 | Valgrind has a special section here because it is a popular tool that is |
| 3394 | highly useful, but valgrind reports are very hard to interpret. |
3441 | highly useful, but valgrind reports are very hard to interpret. |
| 3395 | |
3442 | |
