Hi, Sorry for not commenting on this anytime sooner; here's one thought on it, though:
> I still have portability and reliability concerns, but that's the nature > of the beast with threading. My eventual goal is to abstract out ALL > threading calls into sci_thread_*, and those will map to system-native > stuff (SDL/Win32/pthreads/whatever). This way the various pcmout > subsystems will use the same thread library as everything else. Does the new design explicitly assume the presence of threads to be able to function at all, or could someone eventually implement a forked sound server without using shared memory, by fitting into the current interface? Anyway, please don't completely remove the polls at this point-- once song iterators work, we could poll one of them on systems without either fork() or pthread_create() (or equivalents) in order to get song cues working quickly on new ports (or ports that, by platform, cannot support music/asynchronity). llap, Christoph
