[DGD] FLS

[Raymond Jennings]

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
>