> I'm still running into problems with my threaded encoded, and I think I
> just figured out why.
>
> I have N threads running in parallel calling vorbis_analysis_blockout()
> and vorbis_analysis() to do the number crunching on the input samples.
> They all share a single vorbis_dsp_state -- my understanding was that this
> was ok; they only *read* from the vorbis_dsp_state, therefore not creating
> any race conditions.
>
> However, I think I must have misunderstood, because in reading the code
> from vorbis_analysis_blockout() and the functions that it calls, it
> appears that there are writers of the vorbis_dsp_state (or, more to the
> point, writers to some of the subsidiary data structures).
None of the libvorbis/libvorbisfile functions are safely reentrant for
a given single instance of a data structure. Even the functions that
just look like they read data are modifying state.
>
> _ve_envelope_search(), for example, seems to be a problem. It can realloc
> some data associated with the envelope_lookup. This is apparently causing
> havoc with the multithreaded case -- as far as I can tell, some of my
> threads get stranded using invalidated memory, and Badness happens from
> there.
>
> Am I reading this right? Is this a real problem? ...or was it designed
> that way?
It's designed that way. With my obligations to beta 4 mostly handled,
I'll be spending time this week on docs. Actually, you're just about
qualified at this point to do it too :-)
> Did you intend that vorbis_dsp_state instances can be shared between
> threads? Or are vorbis_dsp_state instances now just stateless, in that
> one can encode vorbis_blocks on different vorbis_dsp_state instances and
> still get continuous audio output? (I don't know how to put that any
> differently; did that make sense?)
vorbis_blocks are standalone but not stateless (you may have several
pointing to one vorbis_dsp_state and each one in parallel with the
others so long as the vorbis_dsp_state is still valid; the reference
to the vorbis_dsp_state is actually readonly). vorbis_dsp_state
structs are definately not stateless. Every call that takes a
vorbis_dsp_state, even ones that look trivial, may change the state.
Monty
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.