[bugs #10554] resizing windows seems to make the main runloop hang

[Alexander Malmberg]

This is an automated notification sent by Savannah.
It relates to:
                bugs #10554, project GNUstep

==============================================================================
 LATEST MODIFICATIONS of bugs #10554:
==============================================================================

               Posted by: Alexander Malmberg <alexm>
               Posted on: 2005-01-13 16:24 (Europe/Stockholm)
    _______________________________________________________

                  Status:                    None -> Unreproducible         
             Open/Closed:                    Open -> Closed                 

    _______________________________________________________

Follow-up Comment:
Short version: If you really really must read from some file on time, use
threads.





My theory on this is that resizing with some(all?) window managers causes the
window manager to "lock" the X server (at the very least, drawing from other
programs is blocked). Since xlib isn't asynchronous, we'll eventually block
in xlib calls in the backend. This is consistent with the fact that other
apps also lock up when I resize windows for a long time.



This is tricky to debug, though, and unfortunately, it doesn't seem to hold.
If I resize for a long time, the app's display will freeze, as expected, but
the main runloop keeps ticking, and watchers still work (even in
NSDefaultRunLoopMode).



Thus, I'm closing this as unreproducible. If some special combination of
window manager/event loop/reading method is necessary to trigger this, we'll
need more information. An example and detailed instructions would be nice.
:)



Note that if we _are_ blocking in xlib calls, then, realistically, there's
nothing we can do to fix this. We don't control the window managers, we don't
control xlib, and afaik, the xlib replacements aren't finished yet. Either
way, there's definitely nothing we can do about the window manager telling
the X server to ignore our drawing.

==============================================================================
 OVERVIEW of bugs #10554:
==============================================================================

URL:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10554>

                 Summary: resizing windows seems to make the main runloop
hang
                 Project: GNUstep
            Submitted by: None
            Submitted on: Sat 10/02/04 at 04:54
                Category: Gui/AppKit
                Severity: 5 - Average
              Item Group: Bug
                  Status: Unreproducible
                 Privacy: Public
             Assigned to: None
             Open/Closed: Closed

    _______________________________________________________


This prevents asynchronous file descriptors from being handled on time and
the application screen area from being updated.

While the latter might not be important, the former is particularly boring.

    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 01/13/05 at 16:24         By: Alexander Malmberg <alexm>
Short version: If you really really must read from some file on time, use
threads.





My theory on this is that resizing with some(all?) window managers causes the
window manager to "lock" the X server (at the very least, drawing from other
programs is blocked). Since xlib isn't asynchronous, we'll eventually block
in xlib calls in the backend. This is consistent with the fact that other
apps also lock up when I resize windows for a long time.



This is tricky to debug, though, and unfortunately, it doesn't seem to hold.
If I resize for a long time, the app's display will freeze, as expected, but
the main runloop keeps ticking, and watchers still work (even in
NSDefaultRunLoopMode).



Thus, I'm closing this as unreproducible. If some special combination of
window manager/event loop/reading method is necessary to trigger this, we'll
need more information. An example and detailed instructions would be nice.
:)



Note that if we _are_ blocking in xlib calls, then, realistically, there's
nothing we can do to fix this. We don't control the window managers, we don't
control xlib, and afaik, the xlib replacements aren't finished yet. Either
way, there's definitely nothing we can do about the window manager telling
the X server to ignore our drawing.

-------------------------------------------------------
Date: Tue 11/09/04 at 23:21         By: Alexander Malmberg <alexm>
Is this with decorations managed by -gui? If so, the resizing code runs the
event loop, but in NSEventTrackingRunLoopMode, just like most other modal
event loops in -gui. If you're watching important descriptors, you probably
want to watch them in that mode in addition to the default mode, and possibly
also all the other standard run loop modes (NSConnectionReplyMode, and
NSModalPanelRunLoopMode (currently unused)).










==============================================================================

This item URL is:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10554>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/