How to create client in child thread

[袁嘉伟]

Yes, I want to achieve that drawing the client from a thread but not the main thread.
Before I have tested that creating display and drawing surface from main thread, and I try to call 
the functions(xdg_surface_xxxx) of wayland to control the client from child thread, but failed.
The reason is function blocked. Through referring some websites, I thought  the drawing and control
might be in the same thread. I continue to test that drawing the client in child thread, but it still block 
in function eglGetDisplay(&display). I don't know why. Because of HMI framework, I must call the function
to control the client in child thread. 
My test code is sample-egl.c. 
Thanks.




在 2016-06-16 04:24:19，"Benoit Gschwind" <gschwind at gnu-log.net> 写道：
>Hello,
>
>The reply from Pekka is about compositor using a client to make the
>rendering, but I not sure this is what you asking for.
>
>Are you talking about building a compositor ? It look like you are
>making a wayland client that try to delegate the drawing to a thread. Is
>it what you want to do ?
>
>Best regards
>
>
>On 15/06/2016 09:24, Pekka Paalanen wrote:
>> On Wed, 15 Jun 2016 12:34:06 +0800 (CST)
>> 袁嘉伟 <yuanjw1025 at 163.com> wrote:
>> 
>>> Hi, All:        I try to create the client and draw it in child
>>> thread failed. If calling functions from child thread, it will block.
>>> So I want to know whether wayland(v1.9) supports to create and redraw
>>> the client in child thread. Perhaps anyone could tell me how to
>>> create a client in child thread.It's better to give me some sample
>>> code.        Thanks.
>> 
>> Hi,
>> 
>> first of all, I would recommend not doing that. Figure out if you
>> really cannot achieve what you want as a separate process instead of a
>> thread in the compositor process.
>> 
>> There is no specific support for making a client in a thread. You have
>> to write the client part as if it was a separate process anyway. This
>> means you have to have an event loop in the client thread, that polls
>> for the Wayland connection fd and anything else it might need to
>> respond to.
>> 
>> Using a simple mutex locking scheme to protect data when accessed from
>> a different thread runs a risk of deadlocks if not done exactly right.
>> That includes not holding any locks across any call that may block,
>> which means you have to choose carefully which libwayland-client
>> functions you call.
>> 
>> Since it is possible that sending any request from the client may
>> (rarely) cause implicit flushing on the connection, I suspect it is not
>> safe to call any Wayland protocol API while holding locks shared with
>> the compositor.
>> 
>> Sharing any locks with the compositor would also be bad because the
>> client could accidentally stall the whole compositor, but that is a
>> caveat you have to decide for yourself.
>> 
>> 
>> Thanks,
>> pq
>> 
>> 
>> 
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160616/a8fd4d7b/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: simple-egl.c
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160616/a8fd4d7b/attachment-0001.c>