I write a fiber scheduler use threads,segfault accur on the code,what's the matter? thanks!

private import core.thread;
private import std.stdio;

private class SyncQueue(T)
{

    private T[] queue;

    public synchronized void push(T o)
    {
        queue ~= o;
    }

    public synchronized T pop()
    {
        T o = null;
        if (queue.length > 1)
        {
            o = queue[0];
            queue = queue[1..$];
        }
        else if (queue.length == 1)
        {
            o = queue[0];
            queue = [];
        }
        return o;
    }

    public bool empty()
    {
        return queue.length ==0;
    }

}

Fiber spawn(Args...)(void function(Args) fn, Args args)
{
    Fiber fiber = Scheduler.instance.createFiber(fn,args);
    Scheduler.instance.schedule(fiber);
    return fiber;
}

Fiber spawn(Args...)(void delegate(Args) dg, Args args)
{
    Fiber fiber = Scheduler.instance.createFiber(dg,args);
    Scheduler.instance.schedule(fiber);
    return fiber;
}

private class Scheduler
{
    private SyncQueue!(Fiber) runQueue;
    private SyncQueue!(Fiber) reuseQueue;

    private static Scheduler _scheduler;

    private static this()
    {
        _scheduler = new Scheduler;
    }

    private this ()
    {
        runQueue   = new SyncQueue!(Fiber);
        reuseQueue = new SyncQueue!(Fiber);
    }

    public void schedule(Fiber fiber)
    {
        runQueue.push(fiber);
    }

    public void run(int threadNum =1)
    {
        ThreadGroup tg = new ThreadGroup;
        for (int i =0;i<threadNum;i++)
        {
            tg.create(
            {
                while (!runQueue.empty)
                {
                    Fiber fiber = runQueue.pop();
                    if (fiber is null)
                    {
                        continue;
                    }
                    else
                    {
                        fiber.call();
                        if (fiber.state == Fiber.State.TERM)
                        {
                            fiber.reset();
                            reuseQueue.push(fiber);//segmentation fault accur here
                        }
                        else
                        {
                            runQueue.push(fiber);//segmentation fault accur here
                        }
                    }
                }
            });
        }
        tg.joinAll;
    }

    public Fiber createFiber(Args...)(void function(Args) fn, Args args)
    {
        void proc()
        {
            fn(args);
        }
        Fiber fiber = reuseQueue.pop();
        if (!fiber)
            fiber = new Fiber(&proc);
        return fiber;
    }

    public Fiber createFiber(Args...)(void delegate(Args) dg, Args args)
    {
        void proc()
        {
            dg(args);
        }
        Fiber fiber = reuseQueue.pop();
        if (!fiber)
            fiber = new Fiber(&proc);
        return fiber;
    }

    public static Scheduler instance()
    {
        return _scheduler;
    }
}

void main()
{
    spawn(
    {
        writefln("%p",cast(void *) Fiber.getThis);
        spawn(
        {
           writefln("%p",cast(void *)Fiber.getThis);
        });
    });

    Scheduler.instance.run(4);
}

Hello Robert,

> If Walter is willing to put dmd under public source control I'd
> happily set this up to automatically compile dmd, run tests suites,
> compile libraries etc. I could even set up a one command/one click
> release candidate/final release thing if needed (maybe even nightly
> builds too).
> 

that would also make setting up RPM/DEB genation something walter dosn't need to worry about.

BCS wrote:

> that would also make setting up RPM/DEB genation something walter
dosn't
> need to worry about.
> 

This have already been done for ldc.

Have a look at http://www.dsource.org/projects/ldc/wiki/WikiStart#Ubuntuldcandldcdailypackages

And at https://launchpad.net/~d-language-packagers/+archive/ppa

(-hg packages are automatically built every night, by a d program, for x86 and x86_64).

On Tue, 12 May 2009 17:25:20 +0000, dsimcha wrote:

> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> dsimcha wrote:
>> > Or is the automatic synchronization of shared variables part not supposed to be implemented yet?
>> The implementation of the synchronization of shared variables is not done yet. It's a big step to just make the default thread local, and to upgrade the static type system.
> 
> Ok, certainly understandable.  In that case, congratulations on the release.

vote++
I like both the shared/tls stuff AND the big emphasis on bug-fixes.

> http://digitalmars.com/d/1.0/changelog.html#new1_045
> 
> http://www.digitalmars.com/d/2.0/changelog.html#new2_030

Seems like D2 is still semi-usable on Mac OS X Tiger,
after recompilation. (official binary is Leopard-only)

Besides for some low-hanging fruit like missing versions
and need to update make and some paths in the makefiles,
there was only a few (known) regressions with threads
and some weird linker issue that I hadn't seen before...


But "hello" does build, and most of the unittests pass:

core.exception.AssertError@core.thread(1664): Assertion failure

dyld: corrupt binary, library ordinal too big
make-3.81: *** [obj/posix/release/unittest/std/regex] Trace/BPT trap

core.exception.RangeError@core.thread(2183): Range violation

--anders

Holy bugfixes, Batman! It took me ten minutes to skip through all the "fixed in dmd1.045" / "fixed in dmd2.030" messages. I'm so happy...

Robert Clipsham wrote:
> Christopher Wright wrote:
>> If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.
> 
> This is already done (to an extent) for ldc after each changeset at http://ldc.buildbot.octarineparrot.com/ (note that this needs updating to llvm /trunk, hence all the failures currently).

As of a few days ago, DStress is now automatically run for LDC, and developers get (almost, it's generally about 30 minutes off) immediate feedback on IRC about any regressions or improvements!

Now that it's set up for ldc, it would be very easy to set it up for dmd if Walter is willing to put it under version control.

Robert Clipsham:
> Now that it's set up for ldc, it would be very easy to set it up for dmd if Walter is willing to put it under version control.

Very good idea, it will improve the improvement process. Let's suggest it to Walter.

Bye,
bearophile