Re: JSON::XS Bool issue in mod_perl (XS--)

[tye]

XS code is almost always buggy (and the bugs are a huge pain in being very "weird" and tending to be huge consumers of a developer's time). JSON::PP uses an algorithm that is efficient in C but is especially slow in Perl. You might have the best luck with some other non-XS implementation. Try JSON::Tiny or some other JSON module.

It should be fairly easy to efficiently parse JSON in Perl, but there are also some typical traps to avoid so many JSON parsing approaches in Perl will be less efficient, so let us know how efficient are the modules that you try.

It is too bad that the author of JSON::XS didn't know that one should thoroughly avoid manipulating Perl data structures from XS code. Creating Perl data structures in XS code is an even worse idea. But this is a case where it actually would be quite hard to do the parsing in XS while creating the Perl data structures in Perl.

But I (wrongly) recall looking at the code and thinking that the creation of the 'true' and 'false' values should've been done in Perl. I guess my instincts were right about that, even though we haven't noticed this problem (also common for XS bugs).

[ikegami]

But I recall looking at the code and thinking that the creation of the 'true' and 'false' values should've been done in Perl.

JSON::XS does create true and false in Perl.

our $true  = do { bless \(my $dummy = 1), "JSON::XS::Boolean" };
our $false = do { bless \(my $dummy = 0), "JSON::XS::Boolean" };

sub true()  { $true  }
sub false() { $false }

So many the problem can be solved by upgrading the module the OP has installed? In any case, the docs say "This module is not guaranteed to be thread safe".

[allyc]

Thanks Davido and Tye for your replies. I will have a look at JSON::Tiny and see if that shows the same issue.

I have just seen in the JSON documentation the following commend;

This module is not guaranteed to be thread safe and there are no plans to change this until Perl gets thread support (as opposed to the horribly slow so-called "threads" which are simply slow and bloated process simulations - use fork, it's much faster, cheaper, better).

I guess that mod_perl comes under threads due to the way that the module is reused over and over so I am not sure it's worth reporting as a bug.

if worst comes to worst I guess I could just use PP for now however some of the objects I need to encode can get quite big and will be slow but I am not sure if that will be noticeable due to the massive performance gains I get from mod_perl.

I will have to run some benchmarks next week to see which method will be the easiest. Thankfully all of the JSON code in my application is centralised so changing the JSON encoder is not a massive issue if XS will not work

[tye]

mod_perl doesn't have to use threads (it usually doesn't, in my experience -- but "ActivePerl" might imply MS Windows which might mean Apache is more likely to be configured to use threads). Even if mod_perl uses threads, that doesn't need to mean that it lets its instances of Perl bounce between threads. So it doesn't need to mean any Perl stuff has to be thread safe.

But I find that people are often confused about these issues (like insisting that one needs to build a threaded Perl to embed it into a threaded application, even when I know the application doesn't share Perl instances between threads). So maybe mod_perl (stupidly) shares Perl instances between threads and this causes your problem.