GitLab

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>

Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

event-loop.c uses WL_EXPORT and wl_list, which are defined in
wayland-util.h.

Include wayland-util.h explicitly, rather than transitively through
wayland-server-core.h.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Sam Spilsbury <smspillaz@gmail.com>

The explicit inclusion of wayland-server.h hides the real dependency, which
is wayland-server-core.h.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>

we don't use assert() anywhere in this file, so remove #include <assert.h>
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>

Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

To fix a shutdown crash in weston's x11 compositor I want to move the
weston X window close to an idle handler.

Since idle handlers are processed at the start of an event loop, the
handler that deals with window close will run at the start of the
next input_loop dispatch, after which the dispatcher blocks on epoll
forever (since all input events that will ever occur have been consumed).

Dispatching idle callbacks both at the start and end of event-loop
processing will prevent this permanent blocking.

Note that just moving the callback dispatch could theoretically
result in an idle callback being delayed indefinitely while waiting
for epoll_wait() to complete.

Callbacks are removed from the list when they're run, so the second
dispatch won't result in any extra calls.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>

Signed-off-by: Philip Withnall <philip at tecnocode.co.uk>
Signed-off-by: Karsten Otto <ottoka at posteo.de>
Reviewed-by: David Fort <contact at hardening-consulting.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

When we add more that one source to a signal, then wayland will
block in wl_event_loop_dispatch. This is due to the attampt to read
from signal's fd each time the source is dispatched.

  wl_event_loop_add_signal(loop, SIGINT, ...);
  wl_event_loop_add_signal(loop, SIGINT, ...);

  /* raise signal .. */

  /* we got two fd's ready, both for the one SIGINT */
  epoll_wait(...) = 2

  [ for (i == 0) ]
      source1->dispatch() --> read(fd1);
  [ for (i == 1) ]
      source2->dispatch() --> read(fd2); /* blocking! */

Reading from fd2 will block, because we got only one signal,
and it was read from fd1.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>

Use wl_log in the last few places where we print to stderr.  Remove
logging in a couple of places where we properly return an error code.

https://bugs.freedesktop.org/show_bug.cgi?id=73339

This implements a simple fix for the blocking problem that occurs when
updating a timer event source after the timer expires, but before its
callback is dispatched. This can happen when another event happens during the
same epoll wakeup as the timer event, and causes the read() call in
wl_event_source_timer_dispatch() to block for the updated duration of the
timer.

We never want this read() call to block, so I believe it makes sense for the
timerfd to be non-blocking, and we simply ignore the case where the read fails
with EAGAIN. We still report all other errors as before, and still ignore the
actual value read from the socket.

With this change, the event_loop_timer_updates unit test case I submitted
previously now passes, and weston appears to work as before.

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>

We need to actually return the destroy-listener, otherwise the return
value is undefined.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>

Exporting unprefixed symbols is a pretty bad idea so don't do that.
Instea of redefining it WL_ARRAY_LENGTH, we just move the define to
our private header.  The scanner generates code that uses ARRAY_LENGTH,
but we can just make it count the number elements and emit an integer
constant instead.

The update callback for the file descriptors was always a bit awkward and
un-intuitive.  The idea was that whenever the protocol code needed to
write data to the fd it would call the 'update' function.  This function
would adjust the mainloop so that it polls for POLLOUT on the fd so we
can eventually flush the data to the socket.

The problem is that in multi-threaded applications, any thread can issue
a request, which writes data to the output buffer and thus triggers the
update callback.  Thus, we'll be calling out with the display mutex
held and may call from any thread.

The solution is to eliminate the udpate callback and just require that
the application or server flushes all connection buffers before blocking.
This turns out to be a simpler API, although we now require clients to
deal with EAGAIN and non-blocking writes.  It also saves a few syscalls,
since the socket will be writable most of the time and most writes will
complete, so we avoid changing epoll to poll for POLLOUT, then write and
then change it back for each write.

When integrating the wayland event-loop into another event-loop, we
currently have no chance of checking whether there are pending idle
sources that have to be called. This patch exports the
"dispatch_idle_sources()" call so other event loops can call this before
going to sleep. This is what wl_event_loop_dispatch() currently does so we
simply allow external event-loops to do the same now.

To avoid breaking existing applications, we keep the call to
dispatch_idle_sources() in wl_event_loop_dispatch() for now. However, if
we want we can remove this later and require every application to call
this manually. This needs to be discussed, but the overhead is negligible
so we will probably leave it as it is.

This finally allows to fully integrate the wayland-server API into
existing event-loops without any nasty workarounds.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>

There is really no need to increment "n" if we never read the value. The
do-while() loop overwrites the value before it is read the first time.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>

Closing an fd will remove it from the epoll set only if it hasn't been
dup'ed.  In other words, the fd is only removed from epoll when all file
descriptors referring to the open file has been close.  We now dup
fd for fd sources, so we need to use EPOLL_CTL_DEL directly now.

Introduced in:
    commit 80f4f0d5
    Author: Jonas Ådahl <jadahl@gmail.com>
    Date:   Wed Mar 21 10:31:24 2012 +0100
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>

Some system C libraries do not have epoll_create1() nor EPOLL_CLOEXEC,
provide a fallback.

Add tests for the wrapper.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>

Instead of directly freeing an event source upon removal put it in a
queue later handled by the event loop; either after a dispatch or upon
event loop destruction.

This is necessary to avoid already queued up event sources to be freed
during some other dispatch callback, causing segmentation faults when
the event loop later tries to handle an event from the freed source.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>

The post-dispatch check on wl_event_loop_dispatch() was not being run
if epoll_wait returned 0 events, making the check unreliable.

When the last idle handler queues another idle handler, we fail to
dispatch that last handler.  The wl_list_for_each_safe loop looks up
the next pointer before running the handler, and at that point it points
to the head of the list and the loop terminates.

Instead, just loop until the list is empty.

There's no good error recovery possible in these cases though.

Idle sources are now just a special case of a checked source.

We pass the poll mask so the dispatch callback can know if there is
data on the fd or not.  The dispatch function must return true if
it dispatched something, in which case we need to do another round of
post-dispatch callbacks."

This lets a source mark itself as ready to dispatch even though the fd
didn't trigger.   What can happen is that for the X11 socket, some other
source callback (the drm fd or a wayland client socket) can cause somebody
to do an X roundtrip (DRI2 get buffers, for example) and queue up events
in the xcb buffer.  When we get back to epoll, the X fd no longer polls
readable and we don't process those events until we get another X event.

The check callback is called after a round of dispatching and lets a source
check if it has data to dispatch and mark itself ready.  Next round of
dispatching will then process it immediately instead of blocking in
epoll_wait().

When the signal handler is removed the corresponding fd is closed. This
should automatically remove it from the epoll set.

When the timer is removed the corresponding fd is closed. This should
automatically remove it from the epoll set.

signal_number was not previously stored, so the callbacks didn't get
a correct signal_number as their first argument.

It can now handle delays greater than 2 seconds without overflowing.

By exposing the epoll fd, we can embed the server event loop in other
main loops suchs as Qt or GTK+.