… | |
… | |
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. |