Are there points in the C extension code that could release the gvl?

[jpcamara]

First off - thanks for the great gem! It's always been such a huge performance boost to any project i've had using JSON.

TL;DR - are there points in the code that could release the gvl and allow for parallelized JSON processing?

The other day I was writing some multi-threaded code utilizing bcrypt-ruby, and was shocked to see full CPU utilization. My computer was getting sluggish and I found that 8 cores were operating at 100%. This made no sense to me since bcrypt is inherently CPU bound and the threads should not have been able to parallelize it on CRuby.

I found this PR from aaron patterson bcrypt-ruby/bcrypt-ruby#124 from 2019 (only released as a new gem version in 2022). It took the crypt_ra call, and wrapped it in a function that ran without the gvl. Here's the main relevant code:

#ifdef HAVE_RUBY_THREAD_H
    value = rb_thread_call_without_gvl(bc_crypt_nogvl, &args, NULL, NULL);
#else
    value = bc_crypt_nogvl((void *)&args);
#endif

My immediate thought was whether other gems with C extensions could benefit from this, and my first thought was OJ. There's a solid chance that no, OJ can't benefit from this because of how it ties back into ruby code or how it works together with other features like callback parsing - but I figured it's worth asking if you've considered it or know of areas that would benefit from it. Thanks!

[Watson1978]

If it is heavy processing such as image processing, it is worth doing. Or it would be useful in cases where there is a long waiting time to get data over the network.
However, I doubt that parsing JSON falls into that category.

There is also the overhead of releasing the GVL.
So, I'm guessing that could rather degrade performance.

[jpcamara]

Yea that's a fair point for the majority of json parsing. I've been in some very large json parsing scenarios where holding the gvl, and being inside c code, means any other thread processing is stuck until that parsing is done.

There are other alternatives of course (like callback parsing, which i've used as well), but having a gvl release in those larger json cases would be beneficial. Difficult to manage the difference though.

[Watson1978]

To release GVL, the available C API is very limited.
https://github.com/ruby/ruby/blob/1c991f3bf40c2e506a819732dd0c4afe5d3c5f46/thread.c#L1631C1-L1633C72

If we were to attempt a GVL release, we would need to reorganize the code significantly.
Because Oj uses the Ruby C API at many places...

[ohler55]

I have timing the various parts of the code and the actual parsing is a ver small fraction of the allocation of Ruby objects. As you probably know any Ruby calls require the GVL. You might notice there are a few variations of the Oj parser from the "fast" parser that does not allocate Ruby object until request and the callback parsers that also only allocate Ruby object if the callback function is defined. As @Watson1978 pointer out, working outside the GVL is great for a task such as image processing to encryption that can be done without making Ruby calls but it does work out so well when Ruby objects have to be created.