… | |
… | |
1662 | will be no polling. |
1662 | will be no polling. |
1663 | |
1663 | |
1664 | =head3 ABI Issues (Largefile Support) |
1664 | =head3 ABI Issues (Largefile Support) |
1665 | |
1665 | |
1666 | Libev by default (unless the user overrides this) uses the default |
1666 | Libev by default (unless the user overrides this) uses the default |
1667 | compilation environment, which means that on systems with optionally |
1667 | compilation environment, which means that on systems with large file |
1668 | disabled large file support, you get the 32 bit version of the stat |
1668 | support disabled by default, you get the 32 bit version of the stat |
1669 | structure. When using the library from programs that change the ABI to |
1669 | structure. When using the library from programs that change the ABI to |
1670 | use 64 bit file offsets the programs will fail. In that case you have to |
1670 | use 64 bit file offsets the programs will fail. In that case you have to |
1671 | compile libev with the same flags to get binary compatibility. This is |
1671 | compile libev with the same flags to get binary compatibility. This is |
1672 | obviously the case with any flags that change the ABI, but the problem is |
1672 | obviously the case with any flags that change the ABI, but the problem is |
1673 | most noticeably with ev_stat and large file support. |
1673 | most noticeably disabled with ev_stat and large file support. |
|
|
1674 | |
|
|
1675 | The solution for this is to lobby your distribution maker to make large |
|
|
1676 | file interfaces available by default (as e.g. FreeBSD does) and not |
|
|
1677 | optional. Libev cannot simply switch on large file support because it has |
|
|
1678 | to exchange stat structures with application programs compiled using the |
|
|
1679 | default compilation environment. |
1674 | |
1680 | |
1675 | =head3 Inotify |
1681 | =head3 Inotify |
1676 | |
1682 | |
1677 | When C<inotify (7)> support has been compiled into libev (generally only |
1683 | When C<inotify (7)> support has been compiled into libev (generally only |
1678 | available on Linux) and present at runtime, it will be used to speed up |
1684 | available on Linux) and present at runtime, it will be used to speed up |
… | |
… | |
3182 | parallel from multiple threads, calls with the same loop parameter must be |
3188 | parallel from multiple threads, calls with the same loop parameter must be |
3183 | done serially (but can be done from different threads, as long as only one |
3189 | done serially (but can be done from different threads, as long as only one |
3184 | thread ever is inside a call at any point in time, e.g. by using a mutex |
3190 | thread ever is inside a call at any point in time, e.g. by using a mutex |
3185 | per loop). |
3191 | per loop). |
3186 | |
3192 | |
3187 | If you want to know which design is best for your problem, then I cannot |
3193 | If you want to know which design (one loop, locking, or multiple loops |
3188 | help you but by giving some generic advice: |
3194 | without or something else still) is best for your problem, then I cannot |
|
|
3195 | help you. I can give some generic advice however: |
3189 | |
3196 | |
3190 | =over 4 |
3197 | =over 4 |
3191 | |
3198 | |
3192 | =item * most applications have a main thread: use the default libev loop |
3199 | =item * most applications have a main thread: use the default libev loop |
3193 | in that thread, or create a separate thread running only the default loop. |
3200 | in that thread, or create a separate thread running only the default loop. |
… | |
… | |
3326 | more than a hundred or so sockets, then likely it needs to use a totally |
3333 | more than a hundred or so sockets, then likely it needs to use a totally |
3327 | different implementation for windows, as libev offers the POSIX readiness |
3334 | different implementation for windows, as libev offers the POSIX readiness |
3328 | notification model, which cannot be implemented efficiently on windows |
3335 | notification model, which cannot be implemented efficiently on windows |
3329 | (Microsoft monopoly games). |
3336 | (Microsoft monopoly games). |
3330 | |
3337 | |
|
|
3338 | A typical way to use libev under windows is to embed it (see the embedding |
|
|
3339 | section for details) and use the following F<evwrap.h> header file instead |
|
|
3340 | of F<ev.h>: |
|
|
3341 | |
|
|
3342 | #define EV_STANDALONE /* keeps ev from requiring config.h */ |
|
|
3343 | #define EV_SELECT_IS_WINSOCKET 1 /* configure libev for windows select */ |
|
|
3344 | |
|
|
3345 | #include "ev.h" |
|
|
3346 | |
|
|
3347 | And compile the following F<evwrap.c> file into your project (make sure |
|
|
3348 | you do I<not> compile the F<ev.c> or any other embedded soruce files!): |
|
|
3349 | |
|
|
3350 | #include "evwrap.h" |
|
|
3351 | #include "ev.c" |
|
|
3352 | |
3331 | =over 4 |
3353 | =over 4 |
3332 | |
3354 | |
3333 | =item The winsocket select function |
3355 | =item The winsocket select function |
3334 | |
3356 | |
3335 | The winsocket C<select> function doesn't follow POSIX in that it |
3357 | The winsocket C<select> function doesn't follow POSIX in that it |
3336 | requires socket I<handles> and not socket I<file descriptors> (it is |
3358 | requires socket I<handles> and not socket I<file descriptors> (it is |
3337 | also extremely buggy). This makes select very inefficient, and also |
3359 | also extremely buggy). This makes select very inefficient, and also |
3338 | requires a mapping from file descriptors to socket handles. See the |
3360 | requires a mapping from file descriptors to socket handles (the Microsoft |
|
|
3361 | C runtime provides the function C<_open_osfhandle> for this). See the |
3339 | discussion of the C<EV_SELECT_USE_FD_SET>, C<EV_SELECT_IS_WINSOCKET> and |
3362 | discussion of the C<EV_SELECT_USE_FD_SET>, C<EV_SELECT_IS_WINSOCKET> and |
3340 | C<EV_FD_TO_WIN32_HANDLE> preprocessor symbols for more info. |
3363 | C<EV_FD_TO_WIN32_HANDLE> preprocessor symbols for more info. |
3341 | |
3364 | |
3342 | The configuration for a "naked" win32 using the Microsoft runtime |
3365 | The configuration for a "naked" win32 using the Microsoft runtime |
3343 | libraries and raw winsocket select is: |
3366 | libraries and raw winsocket select is: |