[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile

  • From: "ttcoder" <trac@xxxxxxxxxxxx>
  • Date: Tue, 08 Nov 2011 09:51:08 -0000

#8007: [app_server] fully unresponsive when resizing window of big textfile
   Reporter:  ttcoder             |      Owner:  axeld
       Type:  bug                 |     Status:  new
   Priority:  normal              |  Milestone:  R1
  Component:  Servers/app_server  |    Version:  R1/Development
 Resolution:                      |   Keywords:
 Blocked By:                      |   Blocking:
Has a Patch:  0                   |   Platform:  All

Comment (by ttcoder):

 @bonefish if you suspect a particular rev. to be the trigger of the
 regression (or if a range of revs are candidate for bisecting) I can test
 that here if you need. But in your latest comment it seems the suspicion
 is not on a recent regression, but in mutex acquisition and thread
 scheduling being "out of phase" with each other ? So a thread can make a
 system call to acquire_sem(), and the kernel may grant that semaphore but
 ''not'' schedule the thread to work (and eventually release the sem)
 immediately, hmmm. The kernel neophyte in me wonders, why not do it the
 other way around: when the kernel schedules a given thread for running
 (according to priority ..etc) at ''that'' time it also looks at what
 system calls are pending for that thread, and grants it the resource.. (if
 available, otherwise it goes on to next schedulable thread).

 In parallel I'm digging a little to find what kind of system resources
 (ports..) are involved in this bug and thus could be the culprit. I've
 been thinking of StyledEdit's BTextView (which is more in my area of
 "expertise")... The hammering could be caused by the long lines "Soft
 Wrap'ping" calculations. Except the bug does not occur on the initial file
 opening with default window size, only when resizing the window (and soft
 wrapping) to a larger size... Note to self: try to uncheck the "wrap long
 lines" menu item and see if StyledEdit still freezes the system.

 More notes to self: when you have a million+ lines to soft-wrap in a
 textfile, that must entail an awful lot of BView|BFont::StringWidth()
 calls. These proably involve a ''synchronous'' round-trip to the
 app_server, with a write_port() call, from within the B_DISPLAY_PRIORITY
 window thread. Unless StyledEdit has a mechanism in place for caching
 string lengths and avoiding such performance hits.. But given how its
 performance degrades I guess it uses normal code. If this explanation
 holds water, it'd mean a minimal test case to replicate the freeze would
 look like (a more compilable version of) this:

 BApplication app;  // create link to app_server
 BWindow win;
 BView view;
 win.AddChild( &view );  // make sure StringWidth() will round-trip to
 app_server (maybe BWindow::Show() is a pre-requisite first?)

 for( int i = 0; i<1000000; i++ )
     float dummy = view.StringWidth( "is this string more thann 80 columns
 and to be wrapped" );

 In BTextView it seems that BFont::GetHeight() is [http://dev.haiku-
 os.org/browser/haiku/trunk/src/kits/interface/TextView.cpp#L3884 called]
 from within a very inner loop, should check if that implies a round-trip
 to app_server... And [http://dev.haiku-
 os.org/browser/haiku/trunk/src/kits/interface/TextView.cpp#L4187 here] is
 an uncached StringWidth(), together with an ifdef'ed cached one, hmmm.

Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:17>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: