Wayland Message Behaviour
ppaalanen at gmail.com
Thu Nov 16 08:37:24 UTC 2017
On Wed, 15 Nov 2017 15:47:32 +0000
"Turner, LewisX" <lewisx.turner at intel.com> wrote:
> Hi Derek and pq,
> Thanks for the further suggestions and comments.
> The idea around multiple threads is a likely candidate. We have added
> a thread and the flush is coming from the extra thread.
> There seems to be two obvious approaches to solving the issue:
> 1) Create a new queue for our new thread and just flush the new queue.
> 2) Signal back to the main thread to request that the queue is
> Do you have any advice/opinion on which approach might be better? Are
> there any examples of taking either approach?
this is about server-side, yes?
There are no such queues server-side, so option 1 is impossible.
Option 2 sounds like you would still be sending Wayland events from
multiple threads. That is not reliable.
I cannot see any way to share Wayland library objects between threads
unless you explicitly add full locking around all libwayland-server
calls. I would guess that will be painful, and it is also impossible,
because your component is not the only one doing those calls, you would
have to patch everything used on the server side.
Multiple threads have never been supported in libwayland-server. There
is literally no locking whatsoever to prevent threads from corrupting
objects by simultaneous access. I cannot stress this enough. The only
solution I can see, if you must have multiple threads, is to architect
your program so that all libwayland-server objects (wl_display,
wl_client, wl_resource, wl_event_loop, etc.) are only ever accessed
from a single thread.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel