On Wed, 21 Feb 2018 11:54:43 +0200 Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Mon, 19 Feb 2018 20:19:04 +0100
> Quentin Glidic <sardemff7+wayl...@sardemff7.net> wrote:
>
> > From: Quentin Glidic <sardemff7+...@sardemff7.net>
> >
> > This will allow compositors to pick any event loop implementation they
> > want, and integrating the libweston components with it.
> > Specifically, idle and timeout sources can now have proper priorities to
> > avoid being ghosted by client event processing.
> >
> > Signed-off-by: Quentin Glidic <sardemff7+...@sardemff7.net>
> > ---
> > compositor/main.c | 182
> > +++++++++++++++++++++++++++++++++++++++++++++++--
> > libweston/compositor.c | 86 +++++++++++++++++++++++
> > libweston/compositor.h | 67 ++++++++++++++++++
> > 3 files changed, 329 insertions(+), 6 deletions(-)
> >
>
> Hi,
>
> in principle, the idea of making an interface for this is ok by me, but
> I would like to hear others' opinions as well.
>
> The comments below are about the API details.
> > @@ -1959,6 +1961,71 @@ weston_pending_output_coldplug(struct
> > weston_compositor *compositor);
> > struct weston_output *
> > weston_output_from_resource(struct wl_resource *resource);
> >
> > +enum weston_event_source_priority {
> > + WESTON_EVENT_SOURCE_PRIORITY_HIGH = -100,
> > + WESTON_EVENT_SOURCE_PRIORITY_DEFAULT = 0,
> > + WESTON_EVENT_SOURCE_PRIORITY_TIMEOUT = 0,
> > + WESTON_EVENT_SOURCE_PRIORITY_FD = 0,
> > + WESTON_EVENT_SOURCE_PRIORITY_IDLE = 200,
> > + WESTON_EVENT_SOURCE_PRIORITY_LOW = 300,
> > +};
>
> There can be several kinds of fd sources etc., maybe the API functions
> should take an int instead of enum as argument? This list will probably
> change in any case to list not high/default/low, but
> input-device/output-device/repaint-timing/shell-timeout/...
It seems I have forgotten how libwayland-server works. For each
readable client socket, it does one read up to a max number of bytes
and processes all the fully received messages in the buffer. It does
this at most once for each connection on one event loop cycle.
The above means that a single client flooding the socket cannot starve
other clients or any other processing either.
Furthermore, all Wayland protocol requests are "fast", meaning that
they shouldn't take very long, which makes it less likely for a
flooding client to be able to hog an unfair portion of the server
processing time. However, this is just a speculation. One would have to
audit all requests and do some testing to verify. One thing coming to
mind would be to create and destroy a huge wl_shm_pool, in case the
mmap()/munmap() overhead is significant.
I stand corrected, maybe we don't need the priorities in the event loop
after all.
Thanks,
pq
pgpPS8tj4AtUA.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
