[bug#50814] [PATCH 4/5] guix: Prepare the UI for continuable &warning exceptions.

[Maxime Devos]

Attila Lendvai schreef op wo 29-09-2021 om 14:50 [+0000]:
> > Do we really need to close and open the connection again every time
> > a continuation is made and resumed? This seems inefficient if a threading
> > mechanism implemented by continuations is used (such as guile-fibers),
> > and there are two threads (‘fibers’) communicating and waiting with/for
> > each other in a loop, causing many ‘context switches’ (i.e., many captured
> > and resumed continuations).
> > 
> > Also note that a connection has some state: to the guix-daemon, it acts as
> > a GC root for everything built with the connection, and everything added to
> > the store (with add-to-store & friends) with that connection ... Simply
> > reconnecting isn't sufficient.
> 
> pardon my ignorance wrt dynamic-wind and call/cc, but does that^ mean
> that 1) i should simply leave the wind part of the dynamic-wind empty
> and move back the open-connection call into the let... or that 2) the
> entire idea of replacing the exception handler with an unwind-protect
> is flawed?

About 1): which 'wind part' of dynamic-wind are you referring to?
The in-guard or the out-guard?

If the out-guard is empty, then the reference to the old connection will
be overwritten when the fiber is paused and resumed, so the old connection
will eventually be GC'ed, thus the daemon forgets some GC roots, leading
to a rare GC bug.

If the in-guard is empty, then the after pausing the fiber and resuming it,
the connection will be closed while the fiber might still need it.

> if 2) then i'll try to smarten up the handler to use raise-continuable
> if the exception is of type &warning.

That should work.  Or simpler: always use raise-continuable.

> or any better ideas?

Conventionally, to emit warnings, the procedure 'warning' from
(guix diagnostics) is used.  See e.g. (guix ci), (guix deprecation), (guix 
gexp),
(guix import ...), various modules under (guix scripts ...), (guix upstream) ...

Is there any reason not to use this pre-existing procedure?

Greetings,
Maxime

signature.asc
Description: This is a digitally signed message part