ObjFW  History of src/OFKernelEventObserver_epoll.m of 2f4e0df8be4b4750

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

Casts are now written like types in variable declarations. file: [662ee50aca] check-in: [4af49a13c3] user: js, branch: trunk, size: 5635 [annotate] [blame] [check-ins using] [diff]

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

The reason for this is that -[valueForKey:] could be confused with
Key Value Coding. file: [345a2363cb] check-in: [1ba9c051a6] user: js, branch: trunk, size: 5532 [annotate] [blame] [check-ins using] [diff]

OFMapTable does not allow using 0 for the key, but stdin has file
descriptor 0. file: [f5a39990c0] check-in: [2c3910e9fd] user: js, branch: trunk, size: 5529 [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: [3e6c82710c] check-in: [85917ea0dd] user: js, branch: 0.8, size: 5498 [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: [d65aafd84c] check-in: [45518ae7b7] user: js, branch: trunk, size: 5499 [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: [f08643e4a0] check-in: [b84490ab4f] user: js, branch: 0.8, size: 6113 [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: [ccbb902e19] check-in: [7ae17af9f0] user: js, branch: trunk, size: 6114 [annotate] [blame] [check-ins using] [diff]

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

kqueue and epoll were not updating _readObjects and _writeObjects
anymore, since this was done by the queue handling code, which they no
longer use after the refactorization. file: [e19549d9cb] check-in: [258b8a4944] user: js, branch: trunk, size: 6170 [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: [02fb70080b] check-in: [e9b4700cb6] user: js, branch: trunk, size: 5811 [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: [8f646c7ee8] check-in: [220513a3f5] user: js, branch: trunk, size: 5754 [annotate] [blame] [check-ins using] [diff]