[DGD] FLS

Wed Oct 4 22:15:21 CEST 2017

The easiest way I can figure out to implement it is to have DGD add a null
element in the position I indicated for each and every frame.  The lib can
take it from there.

This would also be a good way to implement TLS as well.  TLS could just be
FLS for frame 0.  No more fancy code needed in the lib to manually insert
TLS.

Initializing FLS to null instead of napping would be good to reduce cost.
Most frames wouldn't even need to use it.

On Oct 4, 2017 2:39 PM, "Dread Quixadhal" <quixadhal at gmail.com> wrote:

> 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
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd