[Gnash-commit] [bug #42420] potential data races from SWFMovieDefinition::read_all_swf()

[Sandro Santilli]

Follow-up Comment #5, bug #42420 (project gnash):

We know from tests that the parsing is expected to happen in chunks of 64kb
per frame advance (or heartbeat? can't remember).

The tests could be improved, but the point is that there's a predictable
amount of data being parsed when the file is read from the filesystem.

When I tried to understand the behavior it really looked like an attempt to
read ina 64kb buffer w/out waiting for data to be available or not. Being on
the filesystem, those are always available and remain that much until next
frame (hints to write a test).

I'm mentioning this becase I'd love to see improved compatibility with
existing content out there that rely on this characteristic to "assume" the
data is loaded in a specific way.

Other than compatibility, the current threaded model worked fine so I see no
reason to change it. I mean, if it's not to obtain something better.

Whatever intermediate step that can take us to the better compatibility is
welcome. A push parser would be lovely.
Moving the parser to the main thread isn't bad either, but then it would still
need a way to only use what's available, as it cannot block. At that point,
making it parse "at most 64k per call" would make it even to the compatibility
point.

Please keep an eye on tests whatever you do, and consider writing more. I'm
pretty sure we don't have much for the 64k as it'd take a big SWF, and don't
remember we ever built it on purpose.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42420>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/