Patchsets that need review by experienced Wine Developers
louis at museresearch.com
Fri Jan 4 15:33:51 CST 2013
I'm really happy that some of our patches are making it into WINE! If I could chime in...
>>> Not sure why this is needed?
>> I'm not sure why either, but i am guessing it improves things in a
>> linux-rt/VST setting (in fact, removing it causes regressions on my
>> L_pa systems - so i am keeping it.
> This is a really old patch. IIRC there were different long filenames that were being converted to the same 8.3 filename. I don't have more details.
That was because of a name collision that'd happen when running the installer for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files with similar names in one directory, and the installer would name the file one thing but in the file would be another file's contents. IIRC, it was a pretty unusual case.
>>> A new synchronization method using UNIX pipe(2)s.
>>> This is definitely not going in as is...
>> Figured as much :) (that was pretty obvious lol.)
>>> It would be interesting to know what deficit in regular Wine is
>>> fixed by it. wineserver overhead?
>> Yeah, Wineserver is probably the number one thing that slows down
>> when, when you are looking for low-latency / high-performance. (ext4
>> is also terrible on stock settings).
> This removes key synchronization calls from the wineserver and keeps them on the app side. Without it realtime performance is impossible. We developed this with Codeweavers, and they were pretty sure it wasn't general enough for the main fork.
This might also end up being generally useful for programs that are realtime and make a lot of wineserver calls. I believe the mutexes were taking too long to access because they were going through wineserver, which was already handling a lot of other calls in serial. Basically, it was a traffic jam. That's my understanding and recollection, at least (I wasn't the original author of the patch but I did do some work on it later).
More information about the wine-devel