January 2012 - Wine-Devel - list.winehq.org

Re: configure.ac: remove an extraneous semicolon (Clang)

by Ken Thomases

On Jan 30, 2012, at 10:09 PM, Austin English wrote: > @@ -1723,7 +1723,7 @@ then > saved_CFLAGS="$CFLAGS" > CFLAGS="$CFLAGS -Wlogical-op -Werror" > AC_CACHE_CHECK([for broken string.h that generates warnings with -Wlogical-op], ac_cv_c_logicalop_noisy, > - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <string.h>]], [[char*f(const char *h,char n) {return strchr(h,n);}]])],[ac_cv_c_logicalop_noisy=no],[ac_cv_c_logicalop_noisy=yes])) > + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <string.h>]], [[char*f(const char *h,char n) {return strchr(h,n)}]])],[ac_cv_c_logicalop_noisy=no],[ac_cv_c_logicalop_noisy=yes])) > CFLAGS="$saved_CFLAGS" > if test "$ac_cv_c_logicalop_noisy" = "no" > then That doesn't look extraneous to me. Also, static analysis of the configure test programs seems like it would produce tons of noise. Those are often not sane programs by normal standards. Regards, Ken

Jan. 31, 2012

Updated clang-static-analyzer results (just in time for 1.4 ;))

by Austin English

Enjoy: http://www.mediafire.com/?aiomfk1cr9bc61y Using: wine-1.4-rc1-34-g01947e0 LLVM commit 683d1e1d449e6e790ff4c0b6340a4bbf144ff919 / git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk(a)149340 91177308-0d34-0410-b5e6-96231b3b80d8 austin(a)aw21 ~ $ sha1sum scan-build-2012-01-30-1.tar.bz2 8b3b2573c3595c805431b2ab40c6958805f37497 scan-build-2012-01-30-1.tar.bz2 -- -Austin

Jan. 31, 2012

Re: Best way to overlay a filesystem for a Wine app?

by Francois Gouget

On Mon, 30 Jan 2012, Scott Ritchie wrote: [...] > If the user never customizes the app-specific prefix with winecfg or > similar, then copying the new registry should work yes? Application configuration data (think Tools -> Options menu) is often stored in the registry... > > Besides that there are other issues, most of which Dan already > > mentioned: > > * As far as I know most overlay filesystems don't deal well with > > changes in the underlying filesystem. This pretty much breaks the > > upgrade scenario. > > Do you mean upgrading while the filesystem is mounted? Or just any > change at all? It's definitely an issue in the former case. I don't know but would not be surprised if it is also an issue in the latter. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Jan. 30, 2012

Re: [PATCH 2/3] winecoreaudio: Implement the lock-free callback design.

by Peter Rosin

Joerg-Cyril.Hoehle(a)t-systems.com skrev 2012-01-30 18:30: > Of the same vein, one liners like > EnterCS > This-> playing = StateStopped; > LeaveCS > are suspicious too. What does that guarantee? Perhaps that another thread doing as below isn't fooled into calling both one() and three()? EnterCS if (This-> playing == StateRunning) { one(); } two(); if (This-> playing == StateStopped) { three(); } LeaveCS I don't know whether, or not, that has any bearing what-so-ever on the patch under discussion... Cheers, Peter

Jan. 30, 2012

Re: Best way to overlay a filesystem for a Wine app?

by Scott Ritchie

On 01/30/2012 01:58 AM, Francois Gouget wrote: > On Fri, 27 Jan 2012, Scott Ritchie wrote: > [...] >> To me, this sounds an awful lot like an overlay file system. Would >> unionfs-fuse be the correct solution here? The .desktop file that sets >> the Wine prefix and also launches the app could mount the FUSE >> filesystem, and the user-space Wine prefix's files could take priority >> over those in /opt. Stuff like user-modding and update/repair systems >> could work properly in that context as well. > > The main issue with copy-on-write overlay filesystems is that they > cannot deal with registry files for two reasons: > * First, once a file has been written to and thus copied to the > user's wineprefix, it will never be updated when you upgrade the > application's package. This means after an upgrade the user's > system.reg and user.reg files (the latter containing the dll > overrides) will be unchanged which may cause the application to be > broken. Well, provided the app doesn't change it's registry entries, it should be ok then. But couldn't we extend Wine a bit in the other case? For instance, maybe app's changes could be merged in via Wine's normal method of updating the registry on (Wine) upgrade (/usr/share/wine.inf)? It would require giving Wine some sort of switch to point to a supplemental file. > * The second issue is that the registry really contains both > application data and user data. The former should be upgraded while > the latter should be preserved. So neither a copying the new registry > files nor preserving the old registry files policies are appropriate > (and these policies are the only two available to overlay > filesystems). > If the user never customizes the app-specific prefix with winecfg or similar, then copying the new registry should work yes? > Besides that there are other issues, most of which Dan already > mentioned: > * As far as I know most overlay filesystems don't deal well with > changes in the underlying filesystem. This pretty much breaks the > upgrade scenario. Do you mean upgrading while the filesystem is mounted? Or just any change at all? > * They are not available on all Linux distributions (not to talk about > Mac OS X or FreeBSD). But I guess this is fine for a > latest-Ubuntu-only approach (like for menus and the trash!). > Yeah the idea is to do this moving forward rather than create a universal linux package. > Another issue is applications that require a license key to be entered > during installation. This causes trouble for both the overlay and > symlink approaches since both have the packager install the application > and then ship the installed image... along with its single license key. > So for these applications a way to enter the license key on first run > has to be found. > Agreed, keys will be a problem. Thanks, Scott Ritchie

Jan. 30, 2012

Re: winecoreaudio.drv: Improve underrun handling

by Andrew Eikum

On Mon, Jan 30, 2012 at 06:52:36PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andre Eikum wrote: > >>> + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, > >>> + This->public_buffer, 0, NULL, 0, 0, 0, NULL, > >>> + &req_time, &start_time); > >> NULL=ASAP is exactly what we want. We don't want ALSA/dmix behavior, > >> where it'll silently skip over late frames in order to catch up (dunno > >> if MacOSX does this but in my eyes that doesn't matter). > >The AudioQueue API does do this > > What "this" do you mean exactly? > a) like dmix, silently skip over megabytes of submitted frames > should they happen to be late w.r.t. wall time? > b) Play any submitted frames ASAP to the speaker? > You said in #29585 that OSS4 does this. > > What mmdevapi needs is b). It does not appear to care about underruns > and has no dmix-like notion of trying to catch up. > Yes. AudioQueue does (a), which I'm trying to work around by telling the queue to play the buffer at any time after the queue's current time when we detect an underrun (although detecting when the queue is empty needs some work, as Ken pointed out). In ALSA, we use snd_pcm_recover() after underruns, but AudioQueue doesn't seem to have an analogous function that works well. Andrew

Jan. 30, 2012

Re: [PATCH 2/3] winecoreaudio: Implement the lock-free callback design.

by Alexandre Julliard

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > Andrew Eikum wrote: >>I wonder if it's appropriate for code freeze. > You choose: > - either 1.4 keeps the old code as is and suffers random dead-locks, or > - 1.4 integrates code void of race-conditions on the basis of a solid design. Can you point to a real app that triggers the bug? -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2012

Re: winealsa: snd_card_get_name uses strdup (Valgrind). (2nd)

by Alexandre Julliard

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Perhaps that way, the relationship is obvious. > > Please choose whether to apply the original patch #82900 or this one. > It used instead "if(!err)" i.e. the 0 return code that ALSA documents. The previous one was better, but you need to get rid of that cast. -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2012

Re: winecoreaudio.drv: Improve underrun handling

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andre Eikum wrote: >>> + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, >>> + This->public_buffer, 0, NULL, 0, 0, 0, NULL, >>> + &req_time, &start_time); >> NULL=ASAP is exactly what we want. We don't want ALSA/dmix behavior, >> where it'll silently skip over late frames in order to catch up (dunno >> if MacOSX does this but in my eyes that doesn't matter). >The AudioQueue API does do this What "this" do you mean exactly? a) like dmix, silently skip over megabytes of submitted frames should they happen to be late w.r.t. wall time? b) Play any submitted frames ASAP to the speaker? You said in #29585 that OSS4 does this. What mmdevapi needs is b). It does not appear to care about underruns and has no dmix-like notion of trying to catch up. >What do you mean by it doesn't matter? If req_time NULL means ASAP, which is what we need, then the behaviour of req_time NOT NULL as either a or b does not matter, because we should not call it that way. Regards, Jörg Höhle

Jan. 30, 2012

[PATCH 2/3] winecoreaudio: Implement the lock-free callback design.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum wrote: >I wonder if it's appropriate for code freeze. You choose: - either 1.4 keeps the old code as is and suffers random dead-locks, or - 1.4 integrates code void of race-conditions on the basis of a solid design. >When working on this patch, were you able to identify >specifically where the contention is? The "10 liner test hack" I mentioned in bug #29657 was simply to remove OSSpinLock inside the callbacks. No more dead-lock. It worked quite well (over hundred successful test iterations to verify the hypothesis), but it was a time bomb and eventually crashed. Unlike a 10 line hack, a proper solution costs a hundred lines. >The idea of the InTransition state was to handle the lock >release in mid-call. Can we add a check for that state in >the callbacks to solve this problem less intrusively? and then do what? I've never experienced code that works releasing locks mid-call. Quite to the contrary, I'm convinced that such patterns are a sure indicator of a design flaw and bound to cause trouble. Of the same vein, one liners like EnterCS This-> playing = StateStopped; LeaveCS are suspicious too. What does that guarantee? You're right that InTransition is no more needed with my patch. A post code-freeze patch can clean up. More specifically, I've kept it so far because of Wait(event) in Stop, outside the lock. While winealsa would benefit too from a lock-free player as sketched in bug #29531, I'm not considering submitting it for 1.4. The difference is that some apps may suffer audio glitches with winealsa, however any app can suffer a random freeze with winecoreaudio. (Well, perhaps I'll write it meanwhile and if it exhibits significant improvements, submit it anyway). Next on my list for 1.4 is #28388. There too, a random dead-lock in any MIDI playing app is not acceptable IMHO. GetPosition is also crucial for 1.4, regardless of code-freeze. Regards, Jörg Höhle

Jan. 30, 2012