Contrary to what I said in #12, dom::parser is no longer thread safe.
For load and parse it isn't a problem as Ruby's GVL is not released so no concurrency is possible.
However load_many yield back to Ruby code so it allow for concurrent use of the parser, and that cause various parsing errors.
As a solution I wrapped the parser inside a Ruby object so that multiple can exist, and the Ruby GC will handle their lifecycle.
Since parse and load don't allow for concurrency they cause use a single parser, however load_many will create a new one every time.
This refactor also open the door to releasing the GVL during parsing. It could make sense for load at least as users likely expect the GVL to be released on IOs.
Contrary to what I said in #12, dom::parser is no longer thread safe.
For
load
andparse
it isn't a problem as Ruby's GVL is not released so no concurrency is possible.However
load_many
yield back to Ruby code so it allow for concurrent use of the parser, and that cause various parsing errors.As a solution I wrapped the parser inside a Ruby object so that multiple can exist, and the Ruby GC will handle their lifecycle.
Since
parse
andload
don't allow for concurrency they cause use a single parser, howeverload_many
will create a new one every time.This refactor also open the door to releasing the GVL during parsing. It could make sense for
load
at least as users likely expect the GVL to be released on IOs.