<br><br><div class="gmail_quote">On Sat, May 7, 2011 at 12:52 PM, microcai <span dir="ltr"><<a href="mailto:microcai@fedoraproject.org" target="_blank">microcai@fedoraproject.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
于 2011年05月08日 00:30, Mike Paquette 写道:<br>
<div><div></div><div>><br>
> On May 7, 2011, at 8:40 AM, microcai wrote:<br>
><br>
>>> I know some basic theory of compositor. But I still have concern about<br>
>>> client window decorations. I think it is very likely an application<br>
>>> becomes unresponsive during resizing. Or a user tires to resize a<br>
>>> unresponsive window. In that case, I don't know if compositor can draw an<br>
>>> updated title bar or just stretch the outdated window context to the new<br>
>>> size. At same time how the compositor calculate rectangles' size and<br>
>>> position for title bar and buttons?<br>
>>><br>
>>> Peng<br>
>>><br>
>><br>
>> Like I said, the compositor can call the client unconditional via<br>
>> signal. No matter it is live or dead lock.<br>
><br>
> I'm not entirely sure this is a workable idea. Signals are not a reliable inter-process communications mechanism. There are also limits as to what state can be safely modified from within a signal handler. Non-async-signal-safe functions cannot be invoked from a signal handler. That would include functions that alter graphics state. A normal thread of execution within a client may not be coded to anticipate asynchronous modification of the current graphics state.<br>
><br>
> The use of a lock to guard the graphics state is insufficient here. If the graphics state is guarded by a lock, common when multiple asynchronous threads are sharing a graphics state, then the signal handler must also honor that lock. This can lead to a contention problem should the signal handler be invoked on the thread already holding the lock.<br>
><br>
> An application becoming unresponsive during app window resizing is an application design problem, and is best addressed at the application level, not as pat of the window server and compositor design. The window server design should provide mechanisms, but strive to be as free of policy as possible. Usability issues such as an unresponsive application are better handled as part of the user interface policy mechanisms, implemented as part of the toolkits and desktop management logic.<br>
><br>
> The window server can provide the mechanisms to move, hide, show, and resize windows. Decisions as to how to handle unresponsive applications and present UI regarding these applications is best done at a higher level.<br>
><br>
> Mike Paquette<br>
<br>
</div></div>Just notify the client if it's alive. But if the client is sure to be<br>
dead locking in some place (by checking the waiting channel of the<br>
client), call it via signal.<br>
<br>
Since win2k.sys is in the kernel, so windows really does this logic.<br>
<br>
<br>
But, if wayland is going to use client-side decoration, then we should<br>
think more carefully, because we got zero help from the kernel side.<br>
<br>
Even so , client side decoration is still better than server side.<br>
<br>
Peng, client side decoration != client side window management.<br></blockquote><div><br></div><div>Sorry. I don't understand how to use signals to resolve those kind of problems. When an application is locked, it is very likely with memory corruption too. I think libwayland should be a user space library. Its memory is not protected system, and it may be corrupted too. To resolve this problem, you have to find a way to protect the memory used by wayland library. As I know, only two solutions, putting code in kernel or in a separated process. </div>
<div><br></div><div>Peng</div></div>