1. 26 Jul, 2016 1 commit
  2. 07 Jun, 2016 2 commits
  3. 02 Jun, 2016 1 commit
  4. 16 Nov, 2015 1 commit
  5. 23 Jun, 2015 1 commit
  6. 12 Jun, 2015 1 commit
  7. 29 Jan, 2015 1 commit
    • Derek Foreman's avatar
      event-loop: Dispatch idle callbacks twice · 5ec8062d
      Derek Foreman authored
      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: default avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: default avatarGiulio Camuffo <giuliocamuffo@gmail.com>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      5ec8062d
  8. 05 Nov, 2014 1 commit
  9. 18 Aug, 2014 1 commit
    • Marek Chalupa's avatar
      event-loop: make signalfd non-blocking · f2338c8f
      Marek Chalupa authored
      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: default avatarMarek Chalupa <mchqwerty@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      f2338c8f
  10. 30 Apr, 2014 1 commit
  11. 25 Apr, 2014 1 commit
    • Andrew Wedgbury's avatar
      Use non-blocking timerfd to prevent blocking when updating timer event sources · 3e962728
      Andrew Wedgbury authored
      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.
      3e962728
  12. 02 Jul, 2013 1 commit
    • Kristian Høgsberg's avatar
      server: Make wl_object and wl_resource opaque structs · d94a8722
      Kristian Høgsberg authored
      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>
      d94a8722
  13. 24 Jan, 2013 1 commit
  14. 15 Jan, 2013 1 commit
  15. 19 Oct, 2012 1 commit
    • Kristian Høgsberg's avatar
      Move ARRAY_LENGTH out of public headers · bdd272f0
      Kristian Høgsberg authored
      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.
      bdd272f0
  16. 11 Oct, 2012 1 commit
    • Kristian Høgsberg's avatar
      Change filedescriptor API to be thread safe · 53d24713
      Kristian Høgsberg authored
      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.
      53d24713
  17. 12 Sep, 2012 1 commit
    • David Herrmann's avatar
      event-loop: export wl_event_loop_dispatch_idle() · 003a946a
      David Herrmann authored
      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: default avatarDavid Herrmann <dh.herrmann@googlemail.com>
      003a946a
  18. 11 Sep, 2012 1 commit
  19. 08 May, 2012 3 commits
  20. 25 Apr, 2012 1 commit
  21. 21 Mar, 2012 1 commit
    • Jonas Ådahl's avatar
      event-loop: Use two-step destruction of event loop sources. · 80f4f0d5
      Jonas Ådahl authored
      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's avatarJonas Ådahl <jadahl@gmail.com>
      80f4f0d5
  22. 20 Mar, 2012 1 commit
  23. 29 Dec, 2011 1 commit
  24. 29 Oct, 2011 1 commit
    • Kristian Høgsberg's avatar
      event-loop: Fix idle handler dispatch corner case · f86338d6
      Kristian Høgsberg authored
      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.
      f86338d6
  25. 12 Aug, 2011 2 commits
  26. 23 Jun, 2011 1 commit
  27. 29 Apr, 2011 1 commit
  28. 22 Apr, 2011 2 commits
  29. 21 Apr, 2011 1 commit
    • Kristian Høgsberg's avatar
      event-loop: Add an optional post-dispatch source callout · 589e581f
      Kristian Høgsberg authored
      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().
      589e581f
  30. 11 Apr, 2011 1 commit
  31. 14 Mar, 2011 4 commits
  32. 19 Nov, 2010 1 commit