[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