client side decorations
shawn.p.huang at gmail.com
Sun May 8 08:25:31 PDT 2011
On Sat, May 7, 2011 at 12:52 PM, microcai <microcai at fedoraproject.org>wrote:
> 于 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
> >>> updated title bar or just stretch the outdated window context to the
> >>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel