On Wed, 4 Oct 2023 11:09:42 -0400 jleivent <jleiv...@comcast.net> wrote:
> On Wed, 4 Oct 2023 11:26:02 +0300 > Pekka Paalanen <ppaala...@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
pgp29yH6qMJec.pgp
Description: OpenPGP digital signature
