… | |
… | |
3260 | calling select (O(n²)) will likely make this unworkable. |
3260 | calling select (O(n²)) will likely make this unworkable. |
3261 | |
3261 | |
3262 | =back |
3262 | =back |
3263 | |
3263 | |
3264 | |
3264 | |
|
|
3265 | =head1 PORTABILITY REQUIREMENTS |
|
|
3266 | |
|
|
3267 | In addition to a working ISO-C implementation, libev relies on a few |
|
|
3268 | additional extensions: |
|
|
3269 | |
|
|
3270 | =over 4 |
|
|
3271 | |
|
|
3272 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
|
|
3273 | |
|
|
3274 | The type C<sig_atomic_t volatile> (or whatever is defined as |
|
|
3275 | C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different |
|
|
3276 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
|
|
3277 | believed to be sufficiently portable. |
|
|
3278 | |
|
|
3279 | =item C<sigprocmask> must work in a threaded environment |
|
|
3280 | |
|
|
3281 | Libev uses C<sigprocmask> to temporarily block signals. This is not |
|
|
3282 | allowed in a threaded program (C<pthread_sigmask> has to be used). Typical |
|
|
3283 | pthread implementations will either allow C<sigprocmask> in the "main |
|
|
3284 | thread" or will block signals process-wide, both behaviours would |
|
|
3285 | be compatible with libev. Interaction between C<sigprocmask> and |
|
|
3286 | C<pthread_sigmask> could complicate things, however. |
|
|
3287 | |
|
|
3288 | The most portable way to handle signals is to block signals in all threads |
|
|
3289 | except the initial one, and run the default loop in the initial thread as |
|
|
3290 | well. |
|
|
3291 | |
|
|
3292 | =back |
|
|
3293 | |
|
|
3294 | If you know of other additional requirements drop me a note. |
|
|
3295 | |
|
|
3296 | |
3265 | =head1 AUTHOR |
3297 | =head1 AUTHOR |
3266 | |
3298 | |
3267 | Marc Lehmann <libev@schmorp.de>. |
3299 | Marc Lehmann <libev@schmorp.de>. |
3268 | |
3300 | |