[DGD] DGD Kernel function prototypes

[Jared Maddox]

> Date: Tue, 03 May 2011 13:48:18 +0200
> From: "Felix A. Croes" <felix at dworkin.nl>
> Subject: Re: [DGD] DGD Kernel function prototypes
> To: dgd at dworkin.nl
> Message-ID: <E1QHE5S-0004s5-RN at pattern>
>
> Jared Maddox <absinthdraco at gmail.com> wrote:
>
>> I'm writing a kernel extension to allow DGD to create SDL windows.
>> I've gotten much of the work for the display and window functions
>> complete (which is more of a starting point than anything), but I
>> don't know the format for the kernel function's prototypes, so I can't
>> complete this initial work. I grabbed this out of extra.c (and renamed
>> it):
>> char pt_gui[] =
>> {
>>       C_TYPECHECKED | C_STATIC, /* Function traits. */
>>       2,
>>       1,
>>       0,
>>       9,
>>       T_MIXED,
>>       T_STRING,
>>       T_STRING,
>>       T_STRING
>> };
>> But I don't really know how to interpret it. Is the T_MIXED the return
>> type? Is the return type the next-to-last T_STRING (I'm mostly certain
>> that the very last isn't the return type)? What are the numeric values
>> about? In short, how do I figure out the meaning of the fields in the
>> prototype description so that I can specify them correctly?
>
> If at all possible, try to use the LPC extension framework:
>
>    http://sourceforge.net/projects/lpc-ext/
I'll take a look at it. Since I haven't actually started writing the
actual kfuns yet, it might be doable, depending on the details.

> but that may be difficult in your case.
I wouldn't know. I'd thought that the extensions stuff was documented
in the DGD sources, so when I didn't see it there I just assumed that
it wasn't being maintained and skipped straight to kernel functions.

> The meaning of values in
> the array is:
>
>    - class bitflags
>    - number of arguments
>    - number of optional extra arguments
>    - size of the whole array, high byte
>    - size of the whole array, low byte
>    - return type
>    - type of first argument
>    - type of second argument
>    ...
The whole array? Meaning the stack space allocated for the arguments +
return, or something else?

> 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?).

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?

>> Additionally, is there any reason why DGD's main function would need
>> to be in the main thread? Some OS's (Apple, mostly) require all Gui
>> operations to occur in the main thread, so I'm going to have a
>> compiler flag that shifts the main DGD function into another thread,
>> but I need to know whether this is likely to cause problems (I don't
>> think so, but just in case...).
>
> The function dgd_main does not have to be in the main thread.  Indeed,
> with the old Windows port, it wasn't.
Good, that should greatly simplify things.