[DGD] FLS

[Dread Quixadhal]

Other languages can do things like that.  If I’m not mis-remembering, one language had a “volatile” keyword for this purpose.  The idea being, the compiler generates a copy of all the stack variables from the caller into the namespace of the callee, then does the function call.  Since the copies are local to the new stack, they will seem like global variables to the callee, but will go away when they go out of scope.  A decision you’d need to make to implement this is, do you care about call depth?  It’s easier to just copy ALL local variables when setting up the new scope, but this will get more expensive the deeper you go (the more volatile functions you call in a row).  If you didn’t want a()->b()->c() to inherit copies of b AND a, you’d have to mark them so when b calls c, it only copies things local to b.  The overhead of that might be the same as actually just doing the full copy. 😊

Note that this would be at the function level.  Doing this at the object level would be a bit trickier since you’d have to also replicate the function code (calling a shared function could have unintended consequences).

Sent from Mail for Windows 10

From: Raymond Jennings
Sent: Wednesday, October 4, 2017 15:08
To: All about DGD and Hydra
Subject: Re: [DGD] FLS

Hmm...in that case you'd need the cooperation of every function in the
stack.  It is doable though, possibly.

You might need to explicitly "push" and "pop" a separate stack for these
values every time you take care of a function call.

You might also need to interface with your error handler so that you can
"unwind" properly when an exception is thrown

As far as I know, the only way to do it automatically would require masking
call_other to provide the functionality in question.  You'd need to take
careful care not to get into a tangle with your own "frame local storage"
management code.

The underlying DGD engine by itself doesn't allow you to directly intercept
function calls like that, but masking call_other and doing some voodoo of
your own might get you what you need.

As it is I reimplemented call_other myself to provide more stringent and
verbose error checking and it does wonders at flushing out bugs.

On Wed, Oct 4, 2017 at 11:56 AM, Blain <blain20 at gmail.com> wrote:

> I'm talking about one for each frame so that it goes away automatically
> when that frame goes away.  An example use is a variable for the current
> user/player/body in a given frame that is automatically rolled back when
> the frame ends and focus goes back to a previous frame, who's current
> user/player/body variable will then be on top.
>
> On Oct 4, 2017 13:49, "Raymond Jennings" <shentino at gmail.com> wrote:
>
> > Of note, TLSD in kotaka (/home/System/sys/tlsd.c) actually extends the
> TLS
> > concept.  It uses a provided slot from the kernel library and stores a
> > mapping in that slot.
> >
> > That mapping is layered first by subsystem/user and then by string
> > namespace, not only allowing each user/subsystem to have named variables
> in
> > it, but also so that TLSD tiself can enforce access controls to keep
> > different modules from tampering or if necessary even peeking at each
> > other's data.
> >
> > TLSD also allows one module to grant read/readwrite access to other
> > modules.
> >
> > is this the sort of thing you were talking about?
> >
> > On Wed, Oct 4, 2017 at 11:46 AM, Raymond Jennings <shentino at gmail.com>
> > wrote:
> >
> > > Oh, you mean using the stack/call trace as a stash-bin for variables?
> > >
> > > If so, the kernel library already implements that.
> > >
> > > The magic is that array and mapping and lwo arguments are passed by
> > > reference, so if you can get access to it by using call_trace(), then
> the
> > > byref semantics let you tinker with the actual array.
> > >
> > > It's pretty neat way to keep temporary stuff around and is VERY
> > > compartmentalized and can keep your codebase tidy
> > >
> > >
> > > On Wed, Oct 4, 2017 at 11:34 AM, Blain <blain20 at gmail.com> wrote:
> > >
> > >> ({ objname, progname, function,
> > >>    line, extern, FLS, arg1,
> > >>    ..., argn })
> > >>
> > >>
> > >>
> > >> On Oct 4, 2017 13:31, "Raymond Jennings" <shentino at gmail.com> wrote:
> > >>
> > >> > That sounds interesting but...I'm completely confused.
> > >> >
> > >> > Could you explain exactly what "frame-local storage mapping" is?
> > >> >
> > >> > On Wed, Oct 4, 2017 at 10:34 AM, Blain <blain20 at gmail.com> wrote:
> > >> >
> > >> > > Was there any interest in implementing a Frame-local storage
> mapping
> > >> in
> > >> > > DGD?  I'm still trying to decide if it's doable at the lib level.
> So
> > >> day
> > >> > > I've got nothing promising.
> > >> > > ____________________________________________
> > >> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >> > ____________________________________________
> > >> > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >> ____________________________________________
> > >> https://mail.dworkin.nl/mailman/listinfo/dgd
> > >
> > >
> > >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>
____________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd