Forum: Ruby-Gnome 2 buffer updates taking too long

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
033517bc31384402cd139f9532fad84f?d=identicon&s=25 Rick Petrin (blindrage)
on 2009-03-27 17:08
I have searched around and I am not really finding an answer to what I
need.

My program has 10-15 telnet session opened to a bunch of fibre channel
switch command lines. The gui has an output buffer for each switch I
have a valid connection to. Some of the commands I am running on the
switch take considerable time to execute, and while doing so I am not
getting any updates to my buffer that the user can see. What I am
looking for is a why to give priority to the buffer update so the user
knows their command took and is running in the background.

A very edited example follows:

  functionbutton.signal_connect("clicked") {
    puts "Portstatsshow button clicked"
    threadslist = []
    loop to run the following on every switch in the fabric
      threadslist << Thread.new {
        $switchlist[switchname].portstatsshow
      }
    end
    threadslist.each { |aThread|  aThread.join }
  }

The first line in the portstatsshow method is
essentially:

    buffer.insert.end_iter('this is going to take awhile')

I have tried the signal catch code for text_insert and changed with no
luck. I have tried writing and calling a method to place a mark at the
end of the insert and scrolling that mark onscreen. Nothing helps. The
entire portstatsshow method runs to completion before the buffer updates
and shows the user the output. There has to be a way to force the update
to happen when I insert the text and then proceed on with the rest of
the method.
033517bc31384402cd139f9532fad84f?d=identicon&s=25 Rick Petrin (blindrage)
on 2009-03-27 18:15
Disreguard the above. After even more digging I finally found the
following little snippet of code that I stuck into my signal event:

while (Gtk.events_pending?)
      Gtk.main_iteration
    end

Everything is working as I expect now.
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-03-28 19:20
Rick Petrin wrote:
> Disreguard the above. After even more digging I finally found the
> following little snippet of code that I stuck into my signal event:
>
> while (Gtk.events_pending?)
>       Gtk.main_iteration
>     end
>
> Everything is working as I expect now.

This forum is really nice - those snippets, and problems description
often helped me with errors :)
033517bc31384402cd139f9532fad84f?d=identicon&s=25 Rick Petrin (blindrage)
on 2009-04-06 19:03
Well I thought I had this beat, and in one case I did get it doing
exactly what I wanted. However, I am still having an issue getting the
GUI to stay updated when the program is running.

So I guess a bit more background

GTK has a main window. In that window are some button and a notebook
section. The notebook section contains a tab for each telnet session I
have open to a device. The tab contains a buffer and editor scrolled
window. When the program is running there are long sessions where the
buffer should just be updating the information I am seeing in the telnet
session, and this mostly works. The issue is that I might have 15 of
these telnet sessions open at one time each running in its own ruby
thread issuing CLI commands and grabbing output. When things get hopping
it can be 30 seconds between screen updates, and minutes for an update
if I change tabs. Is there an easy way to make sure the main window (and
thereby all the contained windows) cycles from all other threads that
are running without having to rewrite the entire 6000+ (currently) lines
of code to include yield statements for all the different threads?

Thanks for any help.
07aaa2c67e8b41fa38f628356a2b163a?d=identicon&s=25 Roy Wright (royw)
on 2009-04-19 16:55
I'd start with using a profiler like ruby-prof to figure out where the
slow downs are.  Maybe try disassociating the widgets and buffers for
not viewed tabs.  Pay particular attention to the widgets event
handlers, I was amazed with how often some are called (hint move as much
processing (especially db calls) out of the handlers as you can get away
with).

HTH,
Roy
This topic is locked and can not be replied to.