Why do I require a `wl_event_loop_add_idle` in creating a fork-exec wayland client

[Markus Ongyerth]

On 2018/7月/11 09:42, Sichem Zhou wrote:
> Hi All,
> 
> I have a question related to the wl_client creation in the compositor. I
> followed these step like weston did:
> 
> 1. create socketpair.
> 2. fork a process and close `socket[0]` in child, close `socket[1]` in in
> parent process.
> 3. set the `WAYLAND_SOCKET` to `socket[1]`.
> 4. exec the program.

You seem to be missing a few steps here. They probably exist in your code, but 
it suggests to me that you might cause this somewhere else.
I have code [1] that doesn't rely on any idle dispatching and worked fine so 
far.

This includes a single step in the compositor:
3. Set up client with wl_display_create_client


Just lookking at my code, I see and remember that I'm using AF_UNIX and 
SOCK_STREAM arguments for the socketpair, which ones do you pass to yours?


[1] https://github.com/waymonad/waymonad/blob/master/src/Waymonad/Actions/Spawn.hs#L181

ongy

> 
> I found out if I do this directly both compositor and client will stuck in
> the eventloop. It seems the compositor is stuck in the
> `wl_display_flush_clients` and client is stuck in `wl_event_queue_dispatch`
> and internally stuck in the epoll.  So I think both compositor and client
> were waiting each other for some update.
> 
> Then I found out that  I need to pack the code in a
> `wl_event_loop_idle_func_t` and add it to the event_loop. But I am couldn't
> figure out why did the compositor stuck in the first place and why did the
> wl_event_loop_add_idle helped.
> 
> Thanks very much.
> SZ

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180803/889eaf6b/attachment.sig>