On Sat, May 7, 2011 at 12:52 PM, microcai micro...@fedoraproject.orgwrote:
于 2011年05月08日 00:30, Mike Paquette 写道:
On May 7, 2011, at 8:40 AM, microcai wrote:
I know some basic theory of compositor. But I still have concern about
client window decorations. I think it is very likely an application
becomes unresponsive during resizing. Or a user tires to resize a
unresponsive window. In that case, I don't know if compositor can draw
an
updated title bar or just stretch the outdated window context to the
new
size. At same time how the compositor calculate rectangles' size and
position for title bar and buttons?
Peng
Like I said, the compositor can call the client unconditional via
signal. No matter it is live or dead lock.
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.
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.
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.
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.
Mike Paquette
Just notify the client if it's alive. But if the client is sure to be
dead locking in some place (by checking the waiting channel of the
client), call it via signal.
Since win2k.sys is in the kernel, so windows really does this logic.
But, if wayland is going to use client-side decoration, then we should
think more carefully, because we got zero help from the kernel side.
Even so , client side decoration is still better than server side.
Peng, client side decoration != client side window management.
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.
Peng
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
