On 17 Sep, Mark Taylor wrote:
>> A frontend I've been toying with: ...
>> http://evilcode.net/dklame/threaded.c
> Does that code work? It looks ok at first glance.
Without looking at the frontend: how can this work? How is thread N+1
- working on frame N+1 - able to know how much of the bitreservoir it
can use, if thread x to N - with x <= N - is working on frame x to N?
> Latest reports are that lame is thread safe and can do what you are
> trying.
I expect libmp3lame to be reentrant, but not to be thread safe.
My definitions:
- reentrant: multiple threads can call every function in the lib if
they work on independent datasets (in this case: dataset =
outputstream) without disturbing each other.
- thread safe: multiple threads can call every function in the lib,
even if they work on datasets which depend on each other (in this
case: different buffers for the same outputstream) - because the
constraints get fulfilled automatically by the functions, e.g.
by locking of datastructures (to prevent race conditions) and/or some
sort of syncronisation.
If we are thread safe, I want to slap someone into the face because I
haven't seen any commit log which talks about the neccessary data
locking or synchronisation work.
Bye,
Alexander.
--
The best things in life are free, but the
expensive ones are still worth a look.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
--
MP3 ENCODER mailing list archive is at:
http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
