MemoryBarrier patch for dbus windows port built with mingw

[Simon McVittie]

On 25/06/12 19:00, Mark Mikofski wrote:
> +__CRT_INLINE VOID MemoryBarrier(VOID)
> +{
> +  LONG Barrier = 0;
> +  __asm__ __volatile__("xchgl %%eax,%0 "
> +    :"=r" (Barrier));
> +}

As we apparently have to point out periodically, this patch will break
the build in non-gcc compilers, and probably also gcc environments that
*do* have MemoryBarrier (like mingw-w64, which happens to be what's in
Debian, so it's what I use to verify that dbus can still cross-compile).

I don't have any philosophical objection to mingw, but we're certainly
not going to accept a patch that works around a missing declaration in
mingw at the cost of breaking build environments that currently *do*
work (mingw-w64, MSVC). "First, do no harm".

If mingw users want to propose a patch that doesn't cause extra damage
on other platforms and has been confirmed to actually emit a memory
barrier (disassemble _dbus_atomic_get and check that there is one),
great. Here is one possibility (totally untested, I don't even run Windows):

#ifdef __GNUC__
/*
 * mingw doesn't have MemoryBarrier in its headers, but it does
 * compile with gcc, which has the __sync_synchronize builtin.
 * This should hopefully be harmless on other platforms that
 * use gcc, such as mingw-w64, since it basically expands to the
 * same thing.
 */
#   define MemoryBarrier __sync_synchronize
#endif

If there's a patch that doesn't cause regressions in the environments
where dbus currently works, you're welcome to reopen the bug.

Regards,
    S