[DGD] FLS

[Raymond Jennings]

Ahh...yeah.

If you're talking about *local* function call frames that don't go
through call_other and thus can't be overridden, then I'm afraid
that's impossible without  the cooperation of the LPC side.

DGD isn't going to be modified to support this in the driver layer.
Best bet is to establish a FLS convention yourself manually, and if
any callees need to access it, pass a reference to the array in
question.

Modifying DGD is not suppoorted by dworkin and you'll be on your own
if anything crashes.

On Tue, Oct 10, 2017 at 3:55 PM, Blain <blain20 at gmail.com> wrote:
> I'd love to see examples of mimicking this behavior with existing
> capability.
>
> A stack held in the TLS won't step back with the call stack when a given
> frame is deleted.  Old data would persist and become confusing.
>
> Not every frame is invoked with call-other.  Even if they were, using
> call_other would require a variable be manually added to every function in
> the library.
>
> This idea is not only useful to a this_user/body style stack.  It could be
> used in other non-gamr implementations as well.  It's simply frame-based
> volatile data dump.  Temporary redirections of output, i.e. piping, might
> be done here, for example.
>
> How much overhead would something like this add? If a given implementation
> did not utilize it, what kind of unnecessary burden would it impose?  Could
> a compile-time toggle flag be useful here?
>
> I think if it did exist already, many people would already be using it.
>
> On Oct 10, 2017 14:18, <bart at wotf.org> wrote:
>
>> On Tue, 10 Oct 2017 11:47:12 -0700, Raymond Jennings wrote
>> > I said that already :P
>>
>> I must have missed that in the longish thread.
>>
>> >
>> > Two geeks agreeing on the idea though is probably a good sign :)
>>
>> No no, the sky must be falling!
>>
>> Bart
>>
>> >
>> > On Tue, Oct 10, 2017 at 11:48 AM,  <bart at wotf.org> wrote:
>> > > You probably could achieve that from lpc by overriding call_other().
>> > >
>> > > Bart
>> > >
>> > > On Wed, 4 Oct 2017 17:45:38 -0500, Blain wrote
>> > >> I implemented the this_user idea in the kernellib's TLS
>> > >> implementation, but there was no easy way to tell if the setting
>> > >> corresponding to a given frame is expired.  So thus the FLS idea was
>> > >> born.
>> > >>
>> > >> If DGD could supply a null element before the first arg, all else
>> > >> could be handled by the lib.  The current klib's implementation of
>> > >> TLS could also be made to use this instead of having to create
>> > >> wrappers for entry-level functions in driver.c to basically do the
>> > >> same thing (except with only frame 0).
>> > >>
>> > >> On Oct 4, 2017 17:01, "Blain" <blain20 at gmail.com> wrote:
>> > >>
>> > >> > I envisioned looping backward to find the latest setting for
>> implementing
>> > >> > something like this_player(). Obviously not all uses of something
>> like this
>> > >> > would need to do that, though.  Another possible use is to let a
>> frame
>> > >> > store unique data that later frames can query, such as stack-based
>> security.
>> > >> >
>> > >> > On Oct 4, 2017 16:10, "Felix A. Croes" <felix at dworkin.nl> wrote:
>> > >> >
>> > >> >> 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.
>> > >> >>
>> > >> >> This is more than what you called FLS, since it also involves
>> setting a
>> > >> >> new value for each frame, or else falling back to a value provided
>> by a
>> > >> >> previous frame.  I would describe that as stack-based, rather than
>> > >> >> frame-based.
>> > >> >>
>> > >> >> If you're looking for a this_player() equivalent, there is an
>> example
>> > >> >> implementation in the LP 2.4.5 mudlib simulation.  It doesn't use,
>> but
>> > >> >> could be done with, thread-local storage.
>> > >> >>
>> > >> >> Regards,
>> > >> >> Felix Croes
>> > >> >> ____________________________________________
>> > >> >> https://mail.dworkin.nl/mailman/listinfo/dgd
>> > >> >
>> > >> >
>> > >> ____________________________________________
>> > >> https://mail.dworkin.nl/mailman/listinfo/dgd
>> > >
>> > >
>> > > --
>> > > http://www.flickr.com/photos/mrobjective/
>> > > http://www.om-d.org/
>> > >
>> > > ____________________________________________
>> > > https://mail.dworkin.nl/mailman/listinfo/dgd
>> > ____________________________________________
>> > https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>>
>> --
>> http://www.flickr.com/photos/mrobjective/
>> http://www.om-d.org/
>>
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd