On Mon, 2009-06-01 at 08:09 -0400, Robert P. J. Day wrote: > i know i've mentioned this before but i'm still having the > occasional desktop lockup where, when i'm trying to, say, just drag a > window, the cursor changes to the 4-way arrow and just *stays* that > way. i can still move the cursor but it's painfully slow and there's > no way to get control of the system back short of power cycling. > > IIRC, if i'm on a network, i can still ssh in so the underlying > system is still functioning, but there's no way to break out of X > anymore -- ctrl-alt-bs doesn't work. If you're at this kind of failure point, c-a-bs isn't going to save you _anyway_. Cursor position updates are run from the SIGIO handler, which you can think of as a kind of lame version of a thread. But cursor _image_ updates are run from the main loop, because in general they're not safe to do from a signal handler. They can easily involve malloc, which isn't signal-safe; failing that, on some hardware you can't safely - or at least not easily - intersperse cursor image updates with other commands. If you can move the cursor but it doesn't change image when you cross window areas (ie, text fields, or the window manager's resize grips), then you're stuck somewhere away from the main loop. The kicker is that c-a-bs is processed the same way: we enqueue the zap sequence right as we get it from the SIGIO handler, but the actual shutdown is run from the main loop. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
