On Mon, Feb 5, 2018 at 4:27 AM, Keith Packard <kei...@keithp.com> wrote: > Giuseppe Bilotta <giuseppe.bilo...@gmail.com> writes: > >> I'm not sure if this could be implemented without making the server >> more susceptible to DOS attacks, though (basically the same issue I >> see in the blocking AutoList geometry change notification). > > In that case, the Window Manager can already perform DoS attacks by > simply never mapping the window. Similarly, the Compositing Manager can > DoS the system by never painting anything. Given that one generally > starts a Window Manager/Compositing Manager at the start of the session, > and that only one of either can be running at a time, there shouldn't be > any way for such a DoS to occur.
Eh, sometimes I miss the obvious 8-D. So the only difference between the two approaches is that in the current async way the server can cover the latency that would come from waiting for the WM to complete the mapping (or in general other such requests) by processing other events, but this comes at the cost of the complexity inevitably deriving from the asynchronicity itself, both in terms of protocol and in things like trying to guarantee consistency between disparate events affecting the same windows (such as the geometry changes' interaction with the presentation that we discussed so far). I must say I'm a bit conflicted about this. I actually like the mostly asynchronous nature of the X11 protocol (but that might just be a perversion of mine developed over years of HPC). In fact, the thing I like the least about it is that the C language doesn't have something that maps naturally to it (while the C++11 std::future actually do). I do agree however that having some better ways to enforce sequencing in some circumstances would be preferrable. > In any case, we're not likely to change how window management works at > this point; toolkits have dealt with re-directed configuration for over > thirty years at this point. Well, obviously, these would be more along general thoughts about how things could be different for X12 ;-) Or at least design principles that may be kept in mind for future extensions. -- Giuseppe "Oblomov" Bilotta _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel