[DGD] DGD Digest, Vol 58, Issue 4

[Jared Maddox]

> Date: Thu, 05 May 2011 19:27:39 +0200
> From: "Felix A. Croes" <felix at dworkin.nl>
> Subject: Re: [DGD] DGD Kernel function prototypes
> To: dgd at dworkin.nl
> Message-ID: <E1QI2Kx-0001Sd-KB at pattern>
>
> Jared Maddox <absinthdraco at gmail.com> wrote:
>
>>[...]
>> >=A0The meaning of values in
>> > the array is:
>> >
>> > =A0 =A0- class bitflags
>> > =A0 =A0- number of arguments
>> > =A0 =A0- number of optional extra arguments
>> > =A0 =A0- size of the whole array, high byte
>> > =A0 =A0- size of the whole array, low byte
>> > =A0 =A0- return type
>> > =A0 =A0- type of first argument
>> > =A0 =A0- type of second argument
>> > =A0 =A0...
>> The whole array? Meaning the stack space allocated for the arguments +
>> return, or something else?
>
> The function prototype character array, that you asked about.
>
Got it.

>> > Don't forget that DGD can execute code atomically, and kfun calls may
>> > be rolled back.
>> The roll-back worries me somewhat (I need to decide how to allow
>> things to be canceled before I can start on that), but these aren't
>> intended to be atomic functions in the DGD sense, due to the I/O
>> involved in writing to the screen (I assume that's controllable with
>> the class bitflags?).
>
> What precisely is it that you want to control for?
>
I'd been reading a few years back in the mail archives, and noticed
some mention of thread-rollback being introduced for DGD-MP. I was
worried that the LPC-threads might have made it into DGD before they
were used in Hydra, and that I would need to support that.

>> There is one DESIGN issue that I'm going to need to deal with. My
>> current intent is to build 'action messages' and atomically push them
>> onto a C queue, for the render thread to deal with. The render thread
>> then pushes a reply onto another C queue. Is there a DGD-internal api
>> for 'task switching' to a different DGD/LPC -thread, or will the
>> kernel function need to just keep waiting for a reply?
>
> DGD is single-threaded.  There is no task switching, and there are no
> LPC threads.
>
I might skip the render thread stuff, then. I'll have to see if I can
return any results before the call completes.