I added this new function today to solve a slightly obscure problem.  When a non-D thread adds itself to the list of GC scannable threads a Thread instance is allocated, some properties are set, and then the instance is added to the list.  From the time the GC lock is released after the initial allocation to the time the thread is added to the list, there are no GC-visible roots to the data.  The previous thread code tried to solve this by pre-allocating the thread instance for use by the next caller, but it had race and deadlock issues.  I tried adding the thread reference as a GC root, but that still left a race from when the memory was returned by the GC to when it was assigned to the root pointer.  There were a few other attempts, but all had similar issues.

What I really needed was a way to prevent a GC collection while the function executed.  GC.disable/enable were a decent alternative, but I still wasn't crazy about the idea that (admittedly incorrectly written code) could call enable() twice and screw everything up.  So I added gc_atomic() to have the GC basically guarantee that an operation would basically complete without GC interference, and leave the GC free to figure out what that meant.  I'm still wondering whether I should have just used enable/disable, so for now the function isn't exposed in core.memory.  Let me know what you think.

I dropped gc_atomic.  I was getting weird TLS errors, and rather than try and fix them I decided that gc_enable/disable was a better route.

you might be interested to this set of changes I did to tango to get rid of some low probability bugs, and to make my debugging of blip easier:

see
http://www.dsource.org/projects/tango/ticket/1959

ciao
Fawzi

Thanks!  Frankly, the greatest obstacle I have for debugging right now is that debug symbol generation is broken on OSX.  I can get the function that failed at best (sometimes just a stack of "????" symbols).  I've always done a lot of printf debugging with D, but for low-level issues like this, it doesn't really do the trick.

On Jul 22, 2010, at 6:16 PM, Fawzi Mohamed wrote:

> you might be interested to this set of changes I did to tango to get rid of some low probability bugs, and to make my debugging of blip easier:
> 
> see
> http://www.dsource.org/projects/tango/ticket/1959
> 
> ciao
> Fawzi
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Well on the end I did manage to get useful debug info most of the time
compiling everything with debug symbols.
But sometime when being at such a low level everything might go wrong,
even printf might fail because it isn't signal safe... write would be
signal safe, but is a bit a pain to use, but to print just fixed
string it might be a better option...

then there is the thing that osx has the bad habit of keeping "full" locks and other allocation stuff in pools protected by spinlocks in the kernel, and it is possible to suspend a thread with the spinlock taken.

That is why I switched to atomic instead of semaphores.

About allocations I moved the allocations of getAll outside the lock, because starting a GC collection to satisfy that allocation could give problems.

Don't know if any of this might help you with your bug.

Happy debugging

Fawzi
On 23-lug-10, at 03:36, Sean Kelly wrote:

> Thanks!  Frankly, the greatest obstacle I have for debugging right now is that debug symbol generation is broken on OSX.  I can get the function that failed at best (sometimes just a stack of "????" symbols).  I've always done a lot of printf debugging with D, but for low-level issues like this, it doesn't really do the trick.
>
> On Jul 22, 2010, at 6:16 PM, Fawzi Mohamed wrote:
>
>> you might be interested to this set of changes I did to tango to get rid of some low probability bugs, and to make my debugging of blip easier:
>>
>> see
>> http://www.dsource.org/projects/tango/ticket/1959
>>
>> ciao
>> Fawzi
>> _______________________________________________
>> 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

I had a conversation with an OS guy at Apple a while back about how to do collections correctly on OSX.  In short, Semaphores aren't the way to do it.  druntime uses the Mach API instead, and it works a lot like collections on Windows.

On Jul 22, 2010, at 7:18 PM, Fawzi Mohamed wrote:

> Well on the end I did manage to get useful debug info most of the time compiling everything with debug symbols.
> But sometime when being at such a low level everything might go wrong, even printf might fail because it isn't signal safe... write would be signal safe, but is a bit a pain to use, but to print just fixed string it might be a better option...
> 
> then there is the thing that osx has the bad habit of keeping "full" locks and other allocation stuff in pools protected by spinlocks in the kernel, and it is possible to suspend a thread with the spinlock taken.
> 
> That is why I switched to atomic instead of semaphores.
> 
> About allocations I moved the allocations of getAll outside the lock, because starting a GC collection to satisfy that allocation could give problems.
> 
> Don't know if any of this might help you with your bug.
> 
> Happy debugging
> 
> Fawzi
> On 23-lug-10, at 03:36, Sean Kelly wrote:
> 
>> Thanks!  Frankly, the greatest obstacle I have for debugging right now is that debug symbol generation is broken on OSX.  I can get the function that failed at best (sometimes just a stack of "????" symbols).  I've always done a lot of printf debugging with D, but for low-level issues like this, it doesn't really do the trick.
>> 
>> On Jul 22, 2010, at 6:16 PM, Fawzi Mohamed wrote:
>> 
>>> you might be interested to this set of changes I did to tango to get rid of some low probability bugs, and to make my debugging of blip easier:
>>> 
>>> see
>>> http://www.dsource.org/projects/tango/ticket/1959
>>> 
>>> ciao
>>> Fawzi
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

On 23-lug-10, at 04:48, Sean Kelly wrote:

> I had a conversation with an OS guy at Apple a while back about how to do collections correctly on OSX.  In short, Semaphores aren't the way to do it.  druntime uses the Mach API instead, and it works a lot like collections on Windows.

yes I also had used the mach api (that is what I am replacing with atomic ops), but still had (very seldomly) problems. But if you don't see them, then maybe I did something wrong/diffrently.

>
> On Jul 22, 2010, at 7:18 PM, Fawzi Mohamed wrote:
>
>> Well on the end I did manage to get useful debug info most of the
>> time compiling everything with debug symbols.
>> But sometime when being at such a low level everything might go
>> wrong, even printf might fail because it isn't signal safe... write
>> would be signal safe, but is a bit a pain to use, but to print just
>> fixed string it might be a better option...
>>
>> then there is the thing that osx has the bad habit of keeping "full" locks and other allocation stuff in pools protected by spinlocks in the kernel, and it is possible to suspend a thread with the spinlock taken.
>>
>> That is why I switched to atomic instead of semaphores.
>>
>> About allocations I moved the allocations of getAll outside the lock, because starting a GC collection to satisfy that allocation could give problems.
>>
>> Don't know if any of this might help you with your bug.
>>
>> Happy debugging
>>
>> Fawzi
>> On 23-lug-10, at 03:36, Sean Kelly wrote:
>>
>>> Thanks!  Frankly, the greatest obstacle I have for debugging right now is that debug symbol generation is broken on OSX.  I can get the function that failed at best (sometimes just a stack of "????" symbols).  I've always done a lot of printf debugging with D, but for low-level issues like this, it doesn't really do the trick.
>>>
>>> On Jul 22, 2010, at 6:16 PM, Fawzi Mohamed wrote:
>>>
>>>> you might be interested to this set of changes I did to tango to get rid of some low probability bugs, and to make my debugging of blip easier:
>>>>
>>>> see
>>>> http://www.dsource.org/projects/tango/ticket/1959
>>>>
>>>> ciao
>>>> Fawzi
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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