Currently libwayland assumes GNU extensions will be available, but
doesn't define the C standard to use. Instead, let's unconditionally
enable POSIX extensions, and enable GNU extensions on a case-by-case
basis as needed.
Signed-off-by: Simon Ser <contact@emersion.fr>
On Linux the signal will be immediately visible in the epoll_wait() call.
However, on FreeBSD we may need a small delay between kill() call and the
signal being visible to the kevent() call. This sometimes happens when the
signal processing and kevent processing runs on different CPUs in the
kernel, so becomes more likely when the system is under load (e.g. running
all tests in parallel).
See https://github.com/jiixyj/epoll-shim/pull/32
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
The new test verifies that, for a set of timers and a short sequence
of timer update calls, when the event loop is run the timer callbacks
are run in the expected order.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
This change expands the `event_loop_timer` test to use two different
timers with different timeouts; it now implicitly checks that e.g.
both timers do not expire at the same time, and that the first timer
expiring does not prevent the second from doing so. (While such failure
modes are unlikely with timer event sources based on individual
timerfds, they are possible when multiple timers share a common timerfd.)
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
The implementation of timer event sources based on timerfds ensured
specific edge-case behavior with regards to removing and updating timers:
Calls to `wl_event_loop_dispatch` will dispatch all timer event sources
that have expired up to that point, with one exception. When multiple
timer event sources are due to be dispatched in a single call of
`wl_event_loop_dispatch`, calling wl_event_source_remove` from within a
timer event source callback will prevent the removed event source's
callback from being called. Note that disarming or updating one of the
later timers that is due to be dispatched, from within a timer callback,
will NOT prevent that timer's callback from being invoked by
`wl_event_loop_dispatch`.
This commit adds a test that verifies the above behavior. (Because
epoll_wait is not documented to return timerfds in chronological order,
(although it does, in practice), the test code does not depend on the
order in which timers are dispatched.)
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Rather than have two versions of the macro with slightly different
interfaces, just use wl_container_of internally.
This also removes use of statement expressions, a GNU C extension.
Signed-off-by: Michael Forney <mforney@mforney.org>
Some headers and source files have been using types such as uint32_t
without explicitly including stdint.h.
Explicitly include stdint.h where appropriate.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
It may happen that there's some time between the first and the other timer expire.
If epoll_wait is called after the first timer expired and
the other not, it returns only one source to dispatch and therefore
the test fails. To fix that, sleep a while before
wl_event_loop_dispatch() to make sure both timers expired.
To be 100% sure, we could use poll() before calling
wl_event_loop_dispatch(), but that would need modification in libwayland
(need to get the source's fd somehow)
https://bugs.freedesktop.org/show_bug.cgi?id=80594
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Make sure the wl_event_source_timer_update suceeded. Also, fix weird
indentation.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Test if when we get a signal, all signal sources for that signal
get dispatched.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Check value set in handler against an explicit value instead of:
assert(value);
also add one assert() for non-NULL value.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
I've noticed a blocking problem in Wayland's event-loop code when updating
timer event sources. The problem occurs if you update the timer at a point
after is has expired, but before it has been dispatched, i.e. from an event
callback that happens during the same epoll wakeup.
When the timer is subsequently dispatched, wl_event_source_timer_dispatch
blocks for the duration of the new timeout in its call to read() from the
timer fd (which is the expected behaviour according to the man page for
timerfd_settime).
This isn't too uncommon a scenario - for example, a socket with an associated
timeout timer. You'd typically want to update the timer when reading from the
socket. This is how I noticed the issue, since I was setting a timeout of
1 minute, and saw my server blocking for this duration!
The following patch adds a (currently failing) test case to Wayland's
event-loop-test.c. It demonstrates the problem using two timers, which are
set to expire at the same time. The first timer to receive its expiry
callback updates the other timer with a much larger timeout, which then
causes the test to block for this timeout before calling the second timer's
callback.
As for a fix, I'm not so sure (which is why I thought I'd post the failing
test case first to show what I mean). I notice that it doesn't actually do
anything with the value read from the timerfd socket, which gives the number
of times the timer expired since the last read, or when the timer was last
updated (which blocks if the timer hasn't yet expired). I believe this value
should always read as 1 anyway, since we don't use periodic timers.
A simple fix would be to use the TFD_NONBLOCK option when creating the
timerfd, ensuring that the read call won't block. We'd then have to ignore
the case when the read returns EAGAIN.
With the work to add wl_resource accessors and port weston to use them,
we're ready to make wl_resource and wl_object opaque structs. We keep
wl_buffer in the header for EGL stacks to use, but don't expose it by
default. In time we'll remove it completely, but for now it provides a
transition paths for code that still uses wl_buffer.
Reviewed-by: Jason Ekstrand<jason@jlekstrand.net>
It was failing with missing include files.
While here, destroy the ugly "../src/..." include
paths used in the tests that was just hacking around
this problem in the Makefile:
sed -i s/..\\/src\\/// tests/*.c
