[wxruby-users] Thread code questions

[Tim Ferrell]

Well, all is working fine now with a few tweaks... so consider this a 
followup with a small question :-)

I ended up with a situation where the worker thread was not getting 
enough time (i.e. downloads were very slow) with the initial approach of 
using a timer to call Thread.pass every 10ms and, I noticed a slight 
improvement as I lowered that down (eventually) to every 1ms... but this 
still downloaded considerably slower than the "thread-less" console 
version I started from.

In an attempt to address this, I did away with the timer calling 
Thread.pass and elected instead to add a Thread#join(limit) call just 
after the progress bar status is updated, like so:

    # Test the state of the queue and worker progress
    protected
    def monitor_queue
      if not @worker # start queue
        @dialog.show
        process_queue_item(@current_item)
      elsif @worker and @current_item < @queue.size - 1
        finish(@worker.status, @worker[:tmpfile]) if @dialog.cancelled
        # still running?
        if @worker.status # update progress bar
          @dialog.progress_item.value = @worker[:progress]
          @worker.join(0.095) # << this is what I added
        else # start next
          process_queue_item(@current_item += 1)
        end
      else
        finish(@worker.status, @worker[:tmpfile])
      end
    end

As I understand it, the limit parameter gives the Thread a certain 
amount of time to work (in this case 95ms) before resuming the normal 
scheduling behavior ... the end result in this case seems to be a better 
balance between ui responsiveness and thread activity for this 
particular app.

My question: since this is my first use of Thread with wx, does anyone 
see any potential pitfalls I may have overlooked?

I did notice in testing that the Wx::Timer resolution seemed to vary 
significantly from platform to platform (as the docs suggested would be 
the case) so I suppose that there could be a bit of contention between 
the Thread.join call and successive calls to the monitor_queue method...

Would there be any harm in wrapping the Thread.join call with some kind 
of flag to tell monitor_queue to skip over its normal processing if the 
worker thread is currently joined?

    # Test the state of the queue and worker progress
    protected
    def monitor_queue
      if not @working
        if not @worker # start queue
          @dialog.show
          process_queue_item(@current_item)
        elsif @worker and @current_item < @queue.size - 1
          finish(@worker.status, @worker[:tmpfile]) if @dialog.cancelled
          # still running?
          if @worker.status # update progress bar
            @dialog.progress_item.value = @worker[:progress]
            @working = true
            @worker.join(0.095)
            @working = false
          else # start next
            process_queue_item(@current_item += 1)
          end
        else
          finish(@worker.status, @worker[:tmpfile])
        end
      end
    end

Thanks for any feedback...

Cheers,
Tim
-- 
Posted via http://www.ruby-forum.com/.