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. > ... > 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 my understanding of stop_display/display_resume is correct, I might use that. Thanks.
