[Scummvm-devel] Porters, please comment! (Was: CVS: scummvm/sound vorbis.cpp,1.12,1.13)
Max Horn
max at quendi.de
Sun Apr 11 04:37:00 CEST 2004
[just noticed I never replied to this email...]
Am 23.03.2004 um 08:32 schrieb <Torbjorn.E.Andersson at tietoenator.com>:
> Max Horn <max at quendi.de> wrote:
>
>> Yeah, that might be sufficient. Provided the OS supports having
>> multiple (read-only) filehandles for the same file. I think *nix
>> allows
>> that, and Windows probably, too. No idea about the others...
>
> I didn't consider that this might be a limitation. Hmm...
>
> You know a lot more than I do about implementing this sort of things.
> Do
> I understand it correctly if I think that adding locking/unlocking
> would
> mean that file accesses from the main thread would remain unchanged,
> but
> that the mixer would need to lock/unlock the file handle it streams
> sound
> from to ensure that it doesn't change in mid-stream?
I don't think that would be possible: both threads would have to do
locking. Which of course isn't too nice, it's quite easy to forget to
(un)lock.
>
> I take it, then, that just about every function in the File class would
> need to wait for the lock to be released before doing anything.
Yeah. Not pretty :-/
Much nicer would indeed be if it was possible to duplicate File
handles. I.e. have to (read only, of course) File objects for the same
file... but I simply don't know whether this is possible on all our
target systems.
Porters: does your system allow two handles for one file to be at use
(independently - i.e. each should have its own seek position, etc.) ?
This is possible on Unix, and I hope on Windows, too (does anybody know
for sure)? But what about Morphos, Dreamcast, PalmOS, etc. (for PalmOS,
we doN't use threading anyway, so this is slightly less of a concern
there). If needed, we could roll a tiny test program which tests this,
I guess... ?
Bye,
Max
More information about the Scummvm-devel
mailing list