From: "Ludovic Courtès" <ludo@gnu.org>
To: Reepca Russelstein <reepca@russelstein.xyz>
Cc: Josselin Poiret <dev@jpoiret.xyz>,
Christopher Baines <mail@cbaines.net>,
Simon Tournier <zimon.toutoune@gmail.com>,
Mathieu Othacehe <othacehe@gnu.org>,
Tobias Geerinckx-Rice <me@tobias.gr>,
Ricardo Wurmus <rekado@elephly.net>,
69292@debbugs.gnu.org, Christopher Baines <guix@cbaines.net>
Subject: [bug#69292] [PATCH 2/6] store: database: Remove with-statement and associated code.
Date: Tue, 05 Mar 2024 12:05:38 +0100 [thread overview]
Message-ID: <87h6hlc519.fsf@gnu.org> (raw)
In-Reply-To: <87ttlzqbfg.fsf@russelstein.xyz> (Reepca Russelstein's message of "Fri, 23 Feb 2024 12:32:03 -0600")
Hi,
Reepca Russelstein <reepca@russelstein.xyz> skribis:
>> I’m all for removing ‘dynamic-wind’, we’ll have to do it to make it
>> usable in a fiberized context anyway.
>>
>> I’ll let reepca comment.
>
> What is the proper fibers-friendly replacement for dynamic-wind, anyway,
> that is "like dynamic-wind, except when suspending a fiber"? It feels
> like the current interaction between dynamic-wind and fibers is more of
> an accident of how the implementation works; I don't suppose fibers could
> export a transparent replacement, like how it already exports a
> replacement for 'sleep'? Or perhaps the underlying issue is that we
> keep using 'dynamic-wind' in situations where it only makes sense to
> enter or exit the dynamic extent once? Is it time to bring
> 'unwind-protect' back into style? I see that fibers now has a
> dynamic-wind*, should that be preferred?
I’ve come to think that ‘dynamic-wind’ is a problematic abstraction.
What we really want is to perform an effect after a normal exit or when
an exception is thrown. The latter case is actually best handled with
‘with-exception-handler’ (this is what I did for ‘with-store’; see
commit 8ed597f4a261fe188de82cd1f5daed83dba948eb).
(In Cuirass I added ‘unwind-protect’ at one point but in the end it was
not so nice and I eventually removed it.)
> I don't have a strong opinion on these changes, I just want to make sure
> we're all aware of how guile-sqlite3's sqlite-finalize acts with cached
> statements.
Agreed.
Thank you for chiming in!
Ludo’.
next prev parent reply other threads:[~2024-03-05 11:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 19:20 [bug#69292] [PATCH 0/6] Prepare the database code for use in the daemon Christopher Baines
2024-02-20 19:39 ` [bug#69292] [PATCH 1/6] store: database: Remove call-with-savepoint and associated code Christopher Baines
2024-02-20 19:39 ` [bug#69292] [PATCH 2/6] store: database: Remove with-statement " Christopher Baines
2024-02-23 16:35 ` Ludovic Courtès
2024-02-23 18:32 ` Reepca Russelstein via Guix-patches via
2024-03-05 11:05 ` Ludovic Courtès [this message]
2024-02-20 19:39 ` [bug#69292] [PATCH 3/6] store: database: Inline SQL to where it's used Christopher Baines
2024-02-23 16:40 ` Ludovic Courtès
2024-02-20 19:39 ` [bug#69292] [PATCH 4/6] store: database: Stop finalizing prepared statements Christopher Baines
2024-02-22 12:39 ` reepca--- via Guix-patches via
2024-02-26 10:50 ` Christopher Baines
2024-02-20 19:39 ` [bug#69292] [PATCH 5/6] store: database: Refactor sqlite-register Christopher Baines
2024-02-23 16:33 ` Ludovic Courtès
2024-02-20 19:39 ` [bug#69292] [PATCH 6/6] store: database: Rename a couple of procedures Christopher Baines
2024-02-23 16:43 ` Ludovic Courtès
2024-02-26 11:03 ` Christopher Baines
2024-02-27 9:24 ` Ludovic Courtès
2024-04-03 17:35 ` Christopher Baines
2024-02-23 16:31 ` [bug#69292] [PATCH 1/6] store: database: Remove call-with-savepoint and associated code Ludovic Courtès
2024-04-03 17:36 ` bug#69292: [PATCH 0/6] Prepare the database code for use in the daemon Christopher Baines
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6hlc519.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=69292@debbugs.gnu.org \
--cc=dev@jpoiret.xyz \
--cc=guix@cbaines.net \
--cc=mail@cbaines.net \
--cc=me@tobias.gr \
--cc=othacehe@gnu.org \
--cc=reepca@russelstein.xyz \
--cc=rekado@elephly.net \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.