# Ruby 1.9 Threading Support

**URL:** <https://www.ruby-forum.com/t/ruby-1-9-threading-support/212495>\
**Category:** Ruby-Gnome 2\
**Created:** [October 4, 2011, 7:34pm UTC](https://www.ruby-forum.com/t/ruby-1-9-threading-support/212495 "2011-10-04T19:34:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [October 4, 2011, 7:34pm UTC](https://www.ruby-forum.com/t/ruby-1-9-threading-support/212495/1 "2011-10-04T19:34:10Z")

</div>

Hi,

Are there any plans to pepper the codebase with rb\_blocking\_region  
calls? If so, is there a preferred way to approach it?

I’ve attached a sample patch for Gdk::Pixbuf.new that allows loading  
from disk to play nicely with threads, but it’s rather ugly. On the  
plus side, it makes a script like the following take about ~1s instead  
of \>4.5s when run on my 6 core AMD with an 8Mb JPEG.

—8\<—  
require ‘glib2’  
$:.unshift ‘./gdk\_pixbuf2/ext/gdk\_pixbuf2/’  
require ‘gdk\_pixbuf2.so’

require ‘thread’

threads = []  
pixbufs = []

m = Mutex.new  
Thread.new { loop { GC.start; Thread.sleep(0.01) } }  
12.times do  
threads \<\< Thread.new {  
pb = Gdk::Pixbuf.new(ARGV[0])  
m.synchronize { pixbufs \<\< pb }  
}  
end  
threads.each(&:join)  
p pixbufs  
—8\<—

So - any thoughts on whether the best way to implement Ruby 1.9 thread  
support for those sections of ruby-gnome2 which are usefully  
threadable?

TTFN,

G

---

<div class="post-metadata">

**Author:** ![Geoff\_Y](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ac91a4/32.png) [@Geoff\_Y](https://www.ruby-forum.com/u/Geoff_Y)\
**Post date:** [October 4, 2011, 11:12pm UTC](https://www.ruby-forum.com/t/ruby-1-9-threading-support/212495/2 "2011-10-04T23:12:09Z")

</div>

On Tue, Oct 4, 2011 at 19:33, Geoff Y. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Are there any plans to pepper the codebase with rb\_blocking\_region  
> calls? If so, is there a preferred way to approach it?
> 
> I’ve attached a sample patch for Gdk::Pixbuf.new that allows loading  
> from disk to play nicely with threads, but it’s rather ugly. On the  
> plus side, it makes a script like the following take about ~1s instead  
> of \>4.5s when run on my 6 core AMD with an 8Mb JPEG.

Oh, my. I think that the current source has to be reviewed thoroughly  
before we add something as complicated as this.

---

<div class="post-metadata">

**Author:** ![Geoff\_Y](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ac91a4/32.png) [@Geoff\_Y](https://www.ruby-forum.com/u/Geoff_Y)\
**Post date:** [October 5, 2011, 12:27pm UTC](https://www.ruby-forum.com/t/ruby-1-9-threading-support/212495/3 "2011-10-05T12:27:01Z")

</div>

On 4 October 2011 22:11, Nikolai W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> On Tue, Oct 4, 2011 at 19:33, Geoff Y. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > Are there any plans to pepper the codebase with rb\_blocking\_region  
> > calls? If so, is there a preferred way to approach it?
> 
> Oh, my. I think that the current source has to be reviewed thoroughly  
> before we add something as complicated as this.

I did choose one of the most complicated examples - I don’t think  
there are many methods that have quite so many C functions to map  
onto, or fallback options for old versions of GTK, or that call  
rb\_gc() and retry the call if it fails 🙂

The scope of the changes would be limited - for most functions I don’t  
think there’d be much benefit. The main areas I hit and wish could be  
handled in background threads are pixbuf loading, saving, scaling and  
a few librsvg functions. And there are probably a few places in  
poppler.

As I understand it, these functions are prime candidates because they  
can take a noticeable period of time to complete and they don’t  
interact with Ruby C API, so it should be quite safe to release the  
GVL while they’re called.

So, any thoughts on any of the following?

1 - Are there any existing plans for better integration with the Ruby  
1.9 threading model that I’ve missed? Is there something specific  
that we’re waiting for here?

2 - Would it be better to have a struct type & separate function for  
each wrapped function rather than (as in the previously attached  
patch) a single function and an enum/union structure?

3 - Are there any thoughts on guidelines for naming of types and  
functions for use with rb\_thread\_blocking\_region?

Thanks,

## G.

Random Musing - [http://www.frafferz.com/](http://www.frafferz.com/)  
Geek Blog - [http://geoffyoungs.github.com/](http://geoffyoungs.github.com/)

---

<div class="post-metadata">

**Author:** ![Geoff\_Y](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/ac91a4/32.png) [@Geoff\_Y](https://www.ruby-forum.com/u/Geoff_Y)\
**Post date:** [October 5, 2011, 1:17pm UTC](https://www.ruby-forum.com/t/ruby-1-9-threading-support/212495/4 "2011-10-05T13:17:41Z")

</div>

On Wed, Oct 5, 2011 at 12:26, Geoff Y. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> there are many methods that have quite so many C functions to map  
> onto, or fallback options for old versions of GTK, or that call  
> rb\_gc() and retry the call if it fails 🙂

OK. I’d still claim that cleaning up before updating to 3.0 would be  
a good thing to do before we get to optimizing for Ruby 1.9, but this  
does sound like something that we should definitely look into. I’m  
sorry I don’t have any more input, as I didn’t even know that this  
functionality existed.