On Wed, 4 Oct 2023 11:09:42 -0400
jleivent wrote:
> On Wed, 4 Oct 2023 11:26:02 +0300
> Pekka Paalanen wrote:
>
> > ...
> > For the forked clients, there is stop_display()/display_resume().
> > Maybe that helps?
>
> Maybe if I understand their usage correctly. Is this right?: A client
> would send a sequence of requests followed by a stop_display request.
> Anything the client sends after that stop_display request will not be
> processed in the server until the server issues a display_resume event.
Looking at TEST(post_error_to_one_client) for example, it seems
stop_display() blocks until the server resumes. It is used for the
server to return from display_run() so that the server can do its
special thing, and then resume the client(s).
The server can use display_post_resume_events() to let clients resume
without entering its own event loop again, to do more special things
before display_run() again to handle client requests once more.
tests/test-compositor.h contains the existing server-client tools, but
also individual tests might have something useful as well that has not
yet been needed by any other test.
> > ...
> > If you limit your direct marshalling to sequences that are
> > theoretically allowed, doesn't that already help you prove that all
> > those cases are handled correctly?
>
> Yes, as long as everyone believes in the "theoretically allowed" part.
>
> > ...
> > But I guess your goal is to see if using the API correctly could ever
> > trigger an illegal sequence?
>
> That's the goal.
>
> > ...
> > It's also possible to call both server and client APIs from the same
> > thread/process on the same Wayland connection, but you need to be
> > careful to prove it cannot deadlock. That should be much easier since
> > it's all single-threaded, and you just need to make sure the fds have
> > data to read and queues have messages to dispatch when you expect
> > them.
>
> I've been thinking about that. Deadlock is the issue, though.
If you flush the Wayland connection explicitly, you should be able to
reliably avoid the deadlocks. Flushing is public stable API.
> If my understanding of stop_display/display_resume is correct, I might
> use that.
Thanks,
pq
pgp29yH6qMJec.pgp
Description: OpenPGP digital signature
