ObjFW  History of src/OFKernelEventObserver+Private.h of 25f7748cba2d3fd504ccea6b96b483c6cf0d3bdc0c9cb7075a3d3317226f858f

This matches Apple's style. file: [2e13c9e416] check-in: [6b77a5dd8b] user: js, branch: trunk, size: 1059 [annotate] [blame] [check-ins using] [diff]

Forgot to add 2017, even though I already did quite some changes in
2017. file: [63b9067ddf] check-in: [44f45c2e35] user: js, branch: trunk, size: 1059 [annotate] [blame] [check-ins using] [diff]

_readObjects must only be changed from the thread running the observer
and not from a thread adding or removing objects to observe. This is
already handled by the locked queue used by poll and select, so the best
way to solve this is to use the locked queue for kqueue and epoll as
well. file: [38a2edcf5b] check-in: [85917ea0dd] user: js, branch: 0.8, size: 1072 [annotate] [blame] [check-ins using] [diff]

_readObjects must only be changed from the thread running the observer
and not from a thread adding or removing objects to observe. This is
already handled by the locked queue used by poll and select, so the best
way to solve this is to use the locked queue for kqueue and epoll as
well. file: [115d733df8] check-in: [45518ae7b7] user: js, branch: trunk, size: 1053 [annotate] [blame] [check-ins using] [diff]

This was broken by 88f2f03. The problem only existed when something was
in the read buffer, but not processed completely, as after processing
the read buffer, it would go on to wait for data - but since not the
entire read buffer had been processed, it meant there was still data
left there that needed to be handled first. file: [32cc2734b2] check-in: [b84490ab4f] user: js, branch: 0.8, size: 749 [annotate] [blame] [check-ins using] [diff]

This was broken by 88f2f03. The problem only existed when something was
in the read buffer, but not processed completely, as after processing
the read buffer, it would go on to wait for data - but since not the
entire read buffer had been processed, it meant there was still data
left there that needed to be handled first. file: [eb360b3361] check-in: [7ae17af9f0] user: js, branch: trunk, size: 730 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [1372173ce7] check-in: [cec0f072f8] user: js, branch: 0.8, size: 749 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [b8cff57a1b] check-in: [2a27cf3000] user: js, branch: trunk, size: 730 [annotate] [blame] [check-ins using] [diff]

This moves the locked queue for actions to
OFKernelEventObserver_LockedQueue, which is now used for select and
poll, but skipped for kqueue and epoll, as they natively support changes
from another thread.

This fixes the problem that removing an object is delayed until the next
observe call - at which point it might have already been closed, meaning
the fd is no longer available. This was mainly a problem with kqueue, as
closing the fd already removed it from the kqueue, which then resulted
in an error being returned when trying to manually remove the fd from
the kqueue. file: [0581f9845e] check-in: [c5f0c5f9ba] user: js, branch: 0.8, size: 745 [annotate] [blame] [check-ins using] [diff]

This moves the locked queue for actions to
OFKernelEventObserver_LockedQueue, which is now used for select and
poll, but skipped for kqueue and epoll, as they natively support changes
from another thread.

This fixes the problem that removing an object is delayed until the next
observe call - at which point it might have already been closed, meaning
the fd is no longer available. This was mainly a problem with kqueue, as
closing the fd already removed it from the kqueue, which then resulted
in an error being returned when trying to manually remove the fd from
the kqueue. file: [ef9792ab10] check-in: [e9b4700cb6] user: js, branch: trunk, size: 726 [annotate] [blame] [check-ins using] [diff]

Now that we can require GCC >= 4.6, we no longer need to fall back to
using a category on old compilers. file: [2c8d4ea4a1] check-in: [2aca549d60] user: js, branch: trunk, size: 985 [annotate] [blame] [check-ins using] [diff]

This was necessary because select(), poll() and kevent() on FreeBSD and
OS X would sometimes return 0 events, even if there are some, and
sometimes return the correct number of events that were pending, meaning
the number of events returned is unreliable. To make things worse,
whether it returns 0 or the number of events that were pending is
completely non-deterministic on both FreeBSD and OS X (running the same
tests multiple times in a row would make it sometimes work and sometimes
fail).

In order to prevent code from depending on the return value of
-[observeForTimeInterval:] (which would depend on select(), poll() and
kevent() returning the correct number), OFKernelObserver no longer
returns whether there were pending events. It is expected that
-[observe] or -[observeForTimeInterval:] is just called in a loop as
long as events should be handled.

The tests have been changed as well to reflect this. What they do now is
set a deadline and call -[observeForTimeInterval:] with a small timeout
in a loop until the deadline is reached or all events have been handled.

Note: DragonFlyBSD has not been tested, but will most likely behave like
FreeBSD and OS X. file: [dfd89ec8e7] check-in: [220513a3f5] user: js, branch: trunk, size: 947 [annotate] [blame] [check-ins using] [diff]

Not retaining them caused kevent() to be called on an invalid fd. file: [c004806a34] check-in: [1dbe9a4e4e] user: js, branch: trunk, size: 955 [annotate] [blame] [check-ins using] [diff]

This means that OFObject.h imports macros.h now, making it unnecessary
to manually import macros.h in almost every file. And while at it, also
import autorelease.h in OFObject.h, so that this doesn't need to be
manually imported in almost every file as well. file: [9baa15c51b] check-in: [13ee56edf3] user: js, branch: trunk, size: 912 [annotate] [blame] [check-ins using] [diff]