WxRuby Newbie Application Hanging

Desktop wxRuby
1

I have a WxRuby application that takes a few inputs from the user and
uses that information to search through a large file for matches. The
application works very well, with one exception. If I click anywhere
in the frame while the application is searching through the long file,
the application hangs. Has anyone experienced anything similar to
this? Any suggestions on how I can fix this?

Thanks
Jayson

2

Jayson,

This was talked about a few months ago, here are the links to the
conversations.

http://rubyforge.org/pipermail/wxruby-users/2007-May/003064.html

The code you want is in this thread
http://rubyforge.org/pipermail/wxruby-users/2007-June/003152.html

Welcome to wxRuby

Sean

3

Thanks for the assist. Unfortunately this didnt work for me. I added
the code to my on_init method, but no change in the UI hang. Here is
my on_init (some lines left out for brevity). Would you mind having a
look?

def on_init
t = Wx::Timer.new(self, 55)
evt_timer(55) { Thread.pass }
t.start(100)

buildElements
updateStatus('',:setup)
updateStatus(status_a,:and)
updateStatus(status_b,:bnd)
evt_button(SUBMIT_ID)do |event|
  formPassFlag = checkForm
  status = (formPassFlag == true) ? 'Processing...' : 'Form Error'
  updateStatus(status,:and)
  if formPassFlag == true
    @@submit_bt.enable(false)
    threads = []
    threads << Thread.new(){getErrors}
    threads.each{|thread|thread.join}
  end
4

Jayson,

I have not used this technique myself so I may be of little help, have
you tried changing the value passed to t.start? Also try a different
value for the ID of the timer, Wx::ID_HIGHEST + 1 will be guaranteed
not to be used elsewhere.

Sean

5

Maybe a bit OT but I have a question related to threads & wxRuby:

Will threads be fixed in the next stable release of wxRuby?

Multithreading is very useful and it should be possible to use it with
wxRuby in a normal way :slight_smile:

Actually I’m writing an application which needs to download some data
from the internet (about 300-400 html files). It takes some time so I
have to display a progress bar. I must have a separate thread for
downloading files because if I try to do everything in the main thread
the UI is not responsive and the progress bar doesn’t update until I
finish downloading. I have searched the archives of this mailing list
and found this strange workaround with Wx::Timer. It works but to some
extent - for some reason Net::HTTP#read_timeout doesn’t work so if the
connection is interrupted the download never ends (although if I use
it in a ruby script which doesn’t use wxRuby it works perfectly - I
think it uses threads in a way wxRuby doesn’t like).
I didn’t find a workaround yet.

Maybe someone will fix multithreading in wxRuby? I don’t know the
internals of wxRuby so I don’t know how easy/difficult it is to fix
it. But I think that it would improve wxRuby greatly.
For instance - downloading data and showing a progress bar is quite a
typical task - it should be fairly straightforward to code something
like this.

Sorry for a long post.

Other than that - wxRuby is great :slight_smile:

6

What is wrong with multi-threading in wx::ruby. Isn’t the Thread class
a ruby core class?

7

Jacek Nowak wrote:

downloading files because if I try to do everything in the main thread
internals of wxRuby so I don’t know how easy/difficult it is to fix
it. But I think that it would improve wxRuby greatly.
For instance - downloading data and showing a progress bar is quite a
typical task - it should be fairly straightforward to code something
like this.

Sorry for a long post.

Other than that - wxRuby is great :slight_smile:

Hey Jacek,

As I’ve just posted, my suggestion is to look at my tutorial about
writing Networking Clients. You can find it:
http://wxruby.rubyforge.org/wiki/wiki.pl?Sockets It gives you a good
idea of how to allow threads to work with Network Communications.

Any questions, feel free to email me,
Mario S.

8

Lance C. wrote:

What is wrong with multi-threading in wx::ruby. Isn’t the Thread class
a ruby core class?

Hey Lance,

There is a problem with Multi-Threading that you may not realize, Ruby
uses Green Threads, which means, that Ruby is the one in control of all
the threads. It contains the code that actually creates a “Virtual
Thread”, that only the Ruby Interpreter knows about. wxRuby, or rather
wxWidgets in general, uses OS Thread creation. wxRuby currently does
not implement the wxThread class, cause the Ruby interpreter (Atleast as
of 1.8 series) is not Thread compliant. But there are ways around that,
and I’ve posted a tutorial, as previously mentioned twice now, that
shows a work around, that will allow you to work with wxRuby and Ruby’s
green threads.

But yea, there are problems, and work arounds to make some things work.

L8ers,
Mario S.

9

Jayson W. wrote:

buildElements
    threads << Thread.new(){getErrors}
    threads.each{|thread|thread.join}
  end

The problem with this, is that your joining the thread. Once you create
the thread, you don’t need to join it, Thread.pass will pass execution
to it, so that it can run, before it goes to the next one. When you do
thread.join, it’ll actually join that thread, and it becomes the main
thread. So my suggestion to you, is to take out
threads.each{|thread|thread.join} from there, and it should work, and
allow the UI to update. Review my Tutorial at
http://wxruby.rubyforge.org/wiki/wiki.pl?Sockets It’s geared towards
Socket clients, but also shows how to create Threaded Applications.

Any questions, feel free to email me.

Mario S.

10

A bit late to this discussion, but …

Jacek Nowak wrote:

Will threads be fixed in the next stable release of wxRuby?

I don’t think there is a canonical fix. Most of the GUI toolkits suffer
from the same problem (see
Ruby Userspace Threads vs GUI toolkits Roundup). Some
(eg FxRuby) build-in a similar Timer-based workaround to the default App
clas, but I think my preference is to let users who want to use Threads
choose how to schedule the threads using Wx::Timer (it might vary
depending on the need for timing accuracy, parallelism etc).

Part of the problem is documenting this properly, so I added an example
on using threads to the samples for the next release:
http://wxruby.rubyforge.org/svn/trunk/wxruby2/samples/etc/threaded.rb

I have searched the archives of this mailing list
and found this strange workaround with Wx::Timer.
Though it seems a bit strange, it’s very similar to the way Ruby’s
threads scheduler works. It checks every 10ms (I think) to see if it’s
in a place where it can switch context to another thread, and then does
so. The problem with GUI toolkits is that Ruby’s scheduler can’t
interrupt if the main thread is in third-party code, like the wxRuby
library. There, most of the time it’s sitting inside the compiled code’s
event loop, waiting for something to happen. So we need to use a
Wx::Timer to emulate the scheduler and force a switch of Thread context.
It works but to some
extent - for some reason Net::HTTP#read_timeout doesn’t work so if the
connection is interrupted the download never ends
I expect read_timeout uses Threads (ruby’s timeout library does) - but
I’d pursue Mario’s advice as well.
Maybe someone will fix multithreading in wxRuby? I don’t know the
internals of wxRuby so I don’t know how easy/difficult it is to fix
it. But I think that it would improve wxRuby greatly.
Like I say, we could make a “best-guess” fix for common cases, but it’d
be sub-optimal for many users. The other thing that is likely to change
is the arrival of Ruby 1.9 in the next few months, which has operating
system threads instead of green threads.

cheers
alex
Alex