client side decorations

[Peng Huang]

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110508/ce5b49a3/attachment.html>