Branch: refs/heads/master
Home:   https://github.com/D-Programming-Language/druntime

Commit: eddc043364178a89a9146fdd0a665ae610dc245f
    https://github.com/D-Programming-Language/druntime/commit/eddc043364178a89a9146fdd0a665ae610dc245f
Author: Brad Roberts <braddr at puremagic.com>
Date:   2011-02-06 (Sun, 06 Feb 2011)

Changed paths:
  M src/core/sys/osx/mach/kern_return.d
  M src/core/sys/osx/mach/port.d
  M src/core/sys/osx/mach/semaphore.d
  M src/core/sys/osx/mach/thread_act.d
  M src/core/thread.d
  M src/gc/gcx.d
  M src/rt/critical.c
  A src/rt/critical_.d
  M src/rt/mars.h
  M src/rt/memory.d
  M src/rt/monitor.c
  A src/rt/monitor_.d

Log Message:
-----------
Merge branch 'master' of git://github.com/ibuclaw/druntime


Commit: 031f65b587f2041b1030147fa83db2a31a820037
    https://github.com/D-Programming-Language/druntime/commit/031f65b587f2041b1030147fa83db2a31a820037
Author: Brad Roberts <braddr at puremagic.com>
Date:   2011-02-06 (Sun, 06 Feb 2011)

Changed paths:
  M posix.mak
  R src/rt/critical.c
  R src/rt/mars.h
  R src/rt/monitor.c
  M win32.mak

Log Message:
-----------
Finish conversion from critical.c and monitor.d to their .d versions

Grf.. I was afraid of that.. the win32 build is unhappy with these changes.  I'll dig in, but if anyone sees the problem and wants to save me the time, shout.

Thanks,
Brad

On 2/6/2011 4:16 PM, noreply at github.com wrote:
> Branch: refs/heads/master
> Home:   https://github.com/D-Programming-Language/druntime
> 
> Commit: eddc043364178a89a9146fdd0a665ae610dc245f
>     https://github.com/D-Programming-Language/druntime/commit/eddc043364178a89a9146fdd0a665ae610dc245f
> Author: Brad Roberts <braddr at puremagic.com>
> Date:   2011-02-06 (Sun, 06 Feb 2011)
> 
> Changed paths:
>   M src/core/sys/osx/mach/kern_return.d
>   M src/core/sys/osx/mach/port.d
>   M src/core/sys/osx/mach/semaphore.d
>   M src/core/sys/osx/mach/thread_act.d
>   M src/core/thread.d
>   M src/gc/gcx.d
>   M src/rt/critical.c
>   A src/rt/critical_.d
>   M src/rt/mars.h
>   M src/rt/memory.d
>   M src/rt/monitor.c
>   A src/rt/monitor_.d
> 
> Log Message:
> -----------
> Merge branch 'master' of git://github.com/ibuclaw/druntime
> 
> 
> Commit: 031f65b587f2041b1030147fa83db2a31a820037
>     https://github.com/D-Programming-Language/druntime/commit/031f65b587f2041b1030147fa83db2a31a820037
> Author: Brad Roberts <braddr at puremagic.com>
> Date:   2011-02-06 (Sun, 06 Feb 2011)
> 
> Changed paths:
>   M posix.mak
>   R src/rt/critical.c
>   R src/rt/mars.h
>   R src/rt/monitor.c
>   M win32.mak
> 
> Log Message:
> -----------
> Finish conversion from critical.c and monitor.d to their .d versions
> 
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Switching just monitor back to the c version gets win32 back in working shape.  So, exploring from there what's wrong, I went to a hybrid version, the .c file referencing the global variables (_monitor_critsec and inited) extern(C)'ed from the .d version.  Still works.  From there, I moved to using the .d version of _STI_monitor_staticctor.  That works for the druntime unit tests, but not for phobos' tests.

You can see the source of what I used here:
  https://github.com/braddr/druntime/commits/win32-monitor-broken

The point where it works, with a mostly .c file:
  https://github.com/braddr/druntime/commit/6c2f4d1b960c8f227a1ee033f072504a12d94e36

The point where I've moved the ctor to the .d file:
  https://github.com/braddr/druntime/commit/7d43689996a63ee0195a55c8d3836edf5e59e6e6

So.. what am I missing?  Is there something special about win32 functions that start with an underscore?  Is there something special about win32 when it comes to linking one lib into another?  That it works for druntime's unittest and not phobos's is confusing to me.  I do next to no win32 programming (completely zero except for dmd), so I'm unfamiliar with any of it's idiosyncrasies.

Thanks,
Brad

On 2/6/2011 4:47 PM, Brad Roberts wrote:
> Grf.. I was afraid of that.. the win32 build is unhappy with these changes.  I'll dig in, but if anyone sees the problem and wants to save me the time, shout.
> 
> Thanks,
> Brad
> 
> On 2/6/2011 4:16 PM, noreply at github.com wrote:
>> Branch: refs/heads/master
>> Home:   https://github.com/D-Programming-Language/druntime
>>
>> Commit: eddc043364178a89a9146fdd0a665ae610dc245f
>>     https://github.com/D-Programming-Language/druntime/commit/eddc043364178a89a9146fdd0a665ae610dc245f
>> Author: Brad Roberts <braddr at puremagic.com>
>> Date:   2011-02-06 (Sun, 06 Feb 2011)
>>
>> Changed paths:
>>   M src/core/sys/osx/mach/kern_return.d
>>   M src/core/sys/osx/mach/port.d
>>   M src/core/sys/osx/mach/semaphore.d
>>   M src/core/sys/osx/mach/thread_act.d
>>   M src/core/thread.d
>>   M src/gc/gcx.d
>>   M src/rt/critical.c
>>   A src/rt/critical_.d
>>   M src/rt/mars.h
>>   M src/rt/memory.d
>>   M src/rt/monitor.c
>>   A src/rt/monitor_.d
>>
>> Log Message:
>> -----------
>> Merge branch 'master' of git://github.com/ibuclaw/druntime
>>
>>
>> Commit: 031f65b587f2041b1030147fa83db2a31a820037
>>     https://github.com/D-Programming-Language/druntime/commit/031f65b587f2041b1030147fa83db2a31a820037
>> Author: Brad Roberts <braddr at puremagic.com>
>> Date:   2011-02-06 (Sun, 06 Feb 2011)
>>
>> Changed paths:
>>   M posix.mak
>>   R src/rt/critical.c
>>   R src/rt/mars.h
>>   R src/rt/monitor.c
>>   M win32.mak
>>
>> Log Message:
>> -----------
>> Finish conversion from critical.c and monitor.d to their .d versions
>>
>>
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

On Sunday 06 February 2011 20:35:23 Brad Roberts wrote:
> Switching just monitor back to the c version gets win32 back in working shape.  So, exploring from there what's wrong, I went to a hybrid version, the .c file referencing the global variables (_monitor_critsec and inited) extern(C)'ed from the .d version.  Still works.  From there, I moved to using the .d version of _STI_monitor_staticctor.  That works for the druntime unit tests, but not for phobos' tests.
> 
> You can see the source of what I used here:
>   https://github.com/braddr/druntime/commits/win32-monitor-broken
> 
> The point where it works, with a mostly .c file:
> 
> https://github.com/braddr/druntime/commit/6c2f4d1b960c8f227a1ee033f072504a
> 12d94e36
> 
> The point where I've moved the ctor to the .d file:
> 
> https://github.com/braddr/druntime/commit/7d43689996a63ee0195a55c8d3836edf
> 5e59e6e6
> 
> So.. what am I missing?  Is there something special about win32 functions that start with an underscore?  Is there something special about win32 when it comes to linking one lib into another?  That it works for druntime's unittest and not phobos's is confusing to me.  I do next to no win32 programming (completely zero except for dmd), so I'm unfamiliar with any of it's idiosyncrasies.

I don't know anything about this particular case. However, it is quite common for functions which are standard on Posix systems but which are not in standard C to be on Windows except that Microsoft prepends an underscore on them. So, if you have the function func on a Posix system but which isn't standard C, there's a decent chance that it exists on Windows as _func.

It makes it _really_ annoying when writing cross-platform code in C++, since often the function is on both Linux and Windows and does exactly the same thing on both except that for some reason Microsoft decided to put an underscore on the front of it. So, you end up having to write wrapper functions all over the place if you don't want your code to have #ifdef WIN32 and the like spread throughout.

- Jonathan M Davis

To get win32 back into a form that works, I've switched the win32 build back to using the .c version of monitor.  The posix platforms continue to use the .d version.

On 2/6/2011 8:35 PM, Brad Roberts wrote:
> Switching just monitor back to the c version gets win32 back in working shape.  So, exploring from there what's wrong, I went to a hybrid version, the .c file referencing the global variables (_monitor_critsec and inited) extern(C)'ed from the .d version.  Still works.  From there, I moved to using the .d version of _STI_monitor_staticctor.  That works for the druntime unit tests, but not for phobos' tests.
> 
> You can see the source of what I used here:
>   https://github.com/braddr/druntime/commits/win32-monitor-broken
> 
> The point where it works, with a mostly .c file:
>   https://github.com/braddr/druntime/commit/6c2f4d1b960c8f227a1ee033f072504a12d94e36
> 
> The point where I've moved the ctor to the .d file:
>   https://github.com/braddr/druntime/commit/7d43689996a63ee0195a55c8d3836edf5e59e6e6
> 
> So.. what am I missing?  Is there something special about win32 functions that start with an underscore?  Is there something special about win32 when it comes to linking one lib into another?  That it works for druntime's unittest and not phobos's is confusing to me.  I do next to no win32 programming (completely zero except for dmd), so I'm unfamiliar with any of it's idiosyncrasies.
> 
> Thanks,
> Brad
> 
> On 2/6/2011 4:47 PM, Brad Roberts wrote:
>> Grf.. I was afraid of that.. the win32 build is unhappy with these changes.  I'll dig in, but if anyone sees the problem and wants to save me the time, shout.
>>
>> Thanks,
>> Brad
>>
>> On 2/6/2011 4:16 PM, noreply at github.com wrote:
>>> Branch: refs/heads/master
>>> Home:   https://github.com/D-Programming-Language/druntime
>>>
>>> Commit: eddc043364178a89a9146fdd0a665ae610dc245f
>>>     https://github.com/D-Programming-Language/druntime/commit/eddc043364178a89a9146fdd0a665ae610dc245f
>>> Author: Brad Roberts <braddr at puremagic.com>
>>> Date:   2011-02-06 (Sun, 06 Feb 2011)
>>>
>>> Changed paths:
>>>   M src/core/sys/osx/mach/kern_return.d
>>>   M src/core/sys/osx/mach/port.d
>>>   M src/core/sys/osx/mach/semaphore.d
>>>   M src/core/sys/osx/mach/thread_act.d
>>>   M src/core/thread.d
>>>   M src/gc/gcx.d
>>>   M src/rt/critical.c
>>>   A src/rt/critical_.d
>>>   M src/rt/mars.h
>>>   M src/rt/memory.d
>>>   M src/rt/monitor.c
>>>   A src/rt/monitor_.d
>>>
>>> Log Message:
>>> -----------
>>> Merge branch 'master' of git://github.com/ibuclaw/druntime
>>>
>>>
>>> Commit: 031f65b587f2041b1030147fa83db2a31a820037
>>>     https://github.com/D-Programming-Language/druntime/commit/031f65b587f2041b1030147fa83db2a31a820037
>>> Author: Brad Roberts <braddr at puremagic.com>
>>> Date:   2011-02-06 (Sun, 06 Feb 2011)
>>>
>>> Changed paths:
>>>   M posix.mak
>>>   R src/rt/critical.c
>>>   R src/rt/mars.h
>>>   R src/rt/monitor.c
>>>   M win32.mak
>>>
>>> Log Message:
>>> -----------
>>> Finish conversion from critical.c and monitor.d to their .d versions

Jonathan M Davis wrote:
> It makes it _really_ annoying when writing cross-platform code in C++, since often the function is on both Linux and Windows and does exactly the same thing on both except that for some reason Microsoft decided to put an underscore on the front of it. So, you end up having to write wrapper functions all over the place if you don't want your code to have #ifdef WIN32 and the like spread throughout.
>
> 

The "some reason" is so that you can write assembler code that can call any C function. Without the leading _, any C function that has the same spelling as a macro assembler pseudo-op or register will fail to assemble.

Linux avoided that problem by having a really ugly asm syntax that won't conflict with C names. Linux assembler format really sucks all the joy out of writing in assembler.

On Sunday 06 February 2011 23:27:07 Walter Bright wrote:
> Jonathan M Davis wrote:
> > It makes it _really_ annoying when writing cross-platform code in C++, since often the function is on both Linux and Windows and does exactly the same thing on both except that for some reason Microsoft decided to put an underscore on the front of it. So, you end up having to write wrapper functions all over the place if you don't want your code to have #ifdef WIN32 and the like spread throughout.
> 
> The "some reason" is so that you can write assembler code that can call any C function. Without the leading _, any C function that has the same spelling as a macro assembler pseudo-op or register will fail to assemble.
> 
> Linux avoided that problem by having a really ugly asm syntax that won't conflict with C names. Linux assembler format really sucks all the joy out of writing in assembler.

I'm afraid that you lost me on that one. Practically every C function in existence starts with a normal letter rather than an underscore. Why would functions from Microsoft or Posix be any different? What about them causes problems where user-defined functions wouldn't?

I can see why having a C function with the same name as a macro assembler pseudo-op or register might cause a problem, but why wouldn't _all_ C functions have that problem then? The only place that I'm aware of where underscores are typical prepended on C function names is on functions which Microsoft provides which are not standard C functions but almost certainly - if not definitely - can be found on Posix systems (typically as part of the Posix standard). I don't see why those functions would cause problems without underscores but other functions wouldn't.

- Jonathan M Davis

I was just poking around in src/rt and noticed the .c files.  Must have marked fixing this as a "to do" item and forgot about it.  In any case, this is something I want to sort out for the next release, and I'm going to look into it today.

My initial guess about what's happening is that this is an artifact of the code using double-checked locking (there's an existing bug report about his the logic for this is broken) and optimization differences between DMD and DMC.  Seems like the easiest way to see if this is true is just to always do a double-lock instead of a DCL and see if the problem goes away, though the DCL stuff needs to be looked into and fixed regardless.

On Feb 6, 2011, at 8:35 PM, Brad Roberts wrote:

> Switching just monitor back to the c version gets win32 back in working shape.  So, exploring from there what's wrong, I went to a hybrid version, the .c file referencing the global variables (_monitor_critsec and inited) extern(C)'ed from the .d version.  Still works.  From there, I moved to using the .d version of _STI_monitor_staticctor.  That works for the druntime unit tests, but not for phobos' tests.
> 
> You can see the source of what I used here:
>  https://github.com/braddr/druntime/commits/win32-monitor-broken
> 
> The point where it works, with a mostly .c file:
>  https://github.com/braddr/druntime/commit/6c2f4d1b960c8f227a1ee033f072504a12d94e36
> 
> The point where I've moved the ctor to the .d file:
>  https://github.com/braddr/druntime/commit/7d43689996a63ee0195a55c8d3836edf5e59e6e6
> 
> So.. what am I missing?  Is there something special about win32 functions that start with an underscore?  Is there something special about win32 when it comes to linking one lib into another?  That it works for druntime's unittest and not phobos's is confusing to me.  I do next to no win32 programming (completely zero except for dmd), so I'm unfamiliar with any of it's idiosyncrasies.
> 
> Thanks,
> Brad
> 
> On 2/6/2011 4:47 PM, Brad Roberts wrote:
>> Grf.. I was afraid of that.. the win32 build is unhappy with these changes.  I'll dig in, but if anyone sees the problem and wants to save me the time, shout.