I'm doing a performance analysis, part of which involves the creation of instances of an auto class within the inner loop, in order to test D wrt resource contention.

It looks like this.

int worker_proc(void *_arg)
{
    ThreadInfo  threadinfo  =   (ThreadInfo)(_arg);
    int         i;

    threadinfo.result = 0;

    for(i = 0; i < threadinfo.cIterations; ++i)
    {
        auto XUser  user = new XUser;           // Acquire the resource

        // Do stuff here - calculating pi, actually
    }

    return 0;
}

This works fine for up to about 32000 iterations, above which it chokes and the process hangs. I originally suspected it was the operations of XUser() and ~XUser(), which internally lock and unlock a semaphore - will be added to the next release of the SynSoft D libs, if anyone's interested (http://synsoft.org/d.html). So I took out the semaphore calls, in other words the creation/destruction of XUser instances does nothing in particular. This still hangs

The next idea was to change XUser (now not locking the semaphore, remember) to not be an auto class, and to remove the auto keywordfs

    for(i = 0; i < threadinfo.cIterations; ++i)
    {
        XUser  user = new XUser;           // Acquire the resource

Still hangs. Next I decided to forget XUser for a while, and replaced it with an instance of X - X is defined as class X{}

    for(i = 0; i < threadinfo.cIterations; ++i)
    {
        X           x   =   new X;

Still hangs! Finally, I replaced it with instance of Object

    for(i = 0; i < threadinfo.cIterations; ++i)
    {
        Object o   =   new Object;

Still hangs!!

This may be a GC problem, but I was under the impression that auto objects were on the stack, and this started when XUser was an auto class/instance. If auto go on the heap, then it simply looks like the GC has a limit. If autos don't go on the GC, then I have no idea.

Either way it's pretty terminal.

Fix, perchance ... ??

:)

Matthew