Searched hist:280818 (Results 1 - 6 of 6) sorted by last modified time
| /freebsd-11-stable/lib/libc/sys/ | ||
| H A D | kqueue.2 | diff 280818 Sun Mar 29 17:22:32 MDT 2015 kib Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by: jilles Sponsored by: The FreeBSD Foundation MFC after: 2 weeks |
| H A D | interposing_table.c | diff 280818 Sun Mar 29 17:22:32 MDT 2015 kib Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by: jilles Sponsored by: The FreeBSD Foundation MFC after: 2 weeks |
| H A D | Makefile.inc | diff 280818 Sun Mar 29 17:22:32 MDT 2015 kib Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by: jilles Sponsored by: The FreeBSD Foundation MFC after: 2 weeks |
| /freebsd-11-stable/lib/libc/include/ | ||
| H A D | libc_private.h | diff 280818 Sun Mar 29 17:22:32 MDT 2015 kib Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by: jilles Sponsored by: The FreeBSD Foundation MFC after: 2 weeks |
| /freebsd-11-stable/share/man/man3/ | ||
| H A D | pthread_testcancel.3 | diff 280818 Sun Mar 29 17:22:32 MDT 2015 kib Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by: jilles Sponsored by: The FreeBSD Foundation MFC after: 2 weeks |
| /freebsd-11-stable/lib/libthr/thread/ | ||
| H A D | thr_syscalls.c | diff 280818 Sun Mar 29 17:22:32 MDT 2015 kib Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by: jilles Sponsored by: The FreeBSD Foundation MFC after: 2 weeks |
Completed in 204 milliseconds