need help writing tests for specific event orderings

[Pekka Paalanen]

On Wed, 4 Oct 2023 11:09:42 -0400
jleivent <jleivent at comcast.net> wrote:

> On Wed, 4 Oct 2023 11:26:02 +0300
> Pekka Paalanen <ppaalanen at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20231005/4e12143f/attachment.sig>