[DGD] Object upgrading

Raymond Jennings shentino at gmail.com
Wed Jul 4 09:36:32 CEST 2018


On Wed, Jul 4, 2018 at 12:32 AM <bart at wotf.org> wrote:
> On Wed, 4 Jul 2018 00:15:56 -0700, Raymond Jennings wrote
> > On Tue, Jul 3, 2018 at 11:34 PM <bart at wotf.org> wrote:
> > >
> > > On Tue, 3 Jul 2018 17:44:40 -0700, Raymond Jennings wrote
> > >
> > > <snip>
> > >
> > > > > Second question, why suspend the system here, and not at the beginning
> of this
> > > > > entire process?
> > > >
> > > > The suspend is merely intended to protect the upgrade() call from
> > > > being preempted by regular activity.
> > >
> > > I understand WHY you suspend the system, that was not the question, the
> > > question was why do that just before starting the *DATA* upgrade part, and not
> > > before starting the compile.
> > >
> > > Unless you immediately follow with the upgrade after compile (in which case
> > > you will still have outdated code being active), you very likely want to have
> > > a call_out inbetween,
> >
> > ah yes
> >
> > I apologize if I neglected to mention that the upgrade() call takes
> > place in a separate task from the actual compilation.  Due to the
> > outdated code issue you cited, this is obviously something to look
> > out for.
>
> And that is what caused my question.
>
> You do not need to have all dependency info to block call_outs and network
> forsuspending those

Nope, but the recompilation that triggers the code replacement and
queues up the patching process also necessitates the sandboxable
upgrade() call.

Two separate jobs depending on the same recompile.

> > This is how it works in kotaka
>
> Very similar in concept to how it workd on some other libs but different from
> what I would expect in one specific detail, the moment where you 'suspend'. I
> did not read anything in your explanation suggesting that cannot start a bit
> earlier, only that it should not start later.

The suspension's side effects only matter once the task invoking it
completes, since DGD is single threaded (at least from the POV of
LPC).

I just personally prefer to defer the suspension until the call_out
for passing along the call to upgrade is completed.  Technically it
can be done at any time.
>
> >
> > Task 1:
> >
> > * compile
> > -- generating inheritance information, possibly compiling other
> > libraries along the way
> > -- the initd is asked for the patcher
> > * compiled!
> > -- ObjectD->compile(blah blah blah, inherited ...) tells the object
> > manager what was inherited,
> > -- Scour the inheritance tree and gather the patchers for all inheritables
> > -- tag all the clones with call_touch
> > * Suspend System
> > -- isolate the upgrade() cal
> > * call_out
> > -- We start a callout that arranges to call the object's upgrade() function
> >
> > DGD internal:
> > * dump the old code, replace with the new code
> >
> > Task 2:
> > * The callout in ObjectD from task 1 fires.
> > -- ObjectD calls object->upgrade()
> > -- Since the system is suspended, the upgrade() call will happen
> > first before anything else, unless multiple objects were compiled in
> > which case you will have more than one object doing an upgrade()
> > call. -- If the object has been flagged with call_touch and has patchers
> > listed, they will be called first
> >
> > Task 3:
> > * SuspendD eventually notices that there's no more "priority tasks"
> > to run while suspended and automatically releases the system.
> >
> > At any point after task 1 completes, any touched object will trigger
> > calls to the registered patchers listed by it and its inherits.
> >
> > For full information I guess check kotaka's ObjectD and PatchD
> > located in ~System/sys
> >
> > > and that also needs to be protected from other activity,
> > > hence my question: why not protect the entire process, so compile + everything
> > > related to upgrade until you can safely have other activities run again?
> > >
> > > Bart.
> > > --
> > > https://www.bartsplace.net/
> > > https://wotf.org/
> > > https://www.flickr.com/photos/mrobjective/
> > >
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
>
> So ypu do protect that callout.
>
> Bart
> --
> https://www.bartsplace.net/
> https://wotf.org/
> https://www.flickr.com/photos/mrobjective/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd



More information about the DGD mailing list