[D-runtime] gc_atomic

[Fawzi Mohamed]

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