unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH v2 5/5] cli: lazily create the crypto gpg context only when needed
Date: Fri, 18 May 2012 16:37:09 -0400	[thread overview]
Message-ID: <4FB6B2F5.6090105@fifthhorseman.net> (raw)
In-Reply-To: <87txzd9su3.fsf@servo.finestructure.net>

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On 05/18/2012 03:45 PM, Jameson Graef Rollins wrote:
> On Fri, May 18 2012, Austin Clements <amdragon@MIT.EDU> wrote:
>> It's slightly awkward that it's the caller's responsibility to free
>> this lazily constructed object.  That should probably be documented.
>> We could more carefully reference count it, but I think that would
>> actually be worse because the reference count would probably bounce
>> through zero frequently.
> 
> I agree that this is awkward.  Is there a suggestion on how to do it
> better?  We only want to initialize it if it's needed, and only
> _mime_node_create knows that.  And we don't want to free it with
> _mime_node_context_free, or something, only to have to reinitialize it
> again with the next node or message.  Thoughts?

You could provide a "destructor" function for notmuch_crypto_t, which
whoever is responsible for the struct would need to call when they are
ready to dispose of it.

The destructor would just destroy any GMIME crypto contexts pointed to
by the struct, and reset those pointers to NULL.

Since the common workflow is a singleton notmuch_crypto_t that is a
subobject of the singleton notmuch_params_t, you could just call that
destructor function before the notmuch_params_t falls out of scope.

If you want to be fancy/symmetric, you could use the same pattern to
create a "destructor" function for notmuch_params_t (it would just
invoke the destructor on its crypto member), but this seems like
overkill to me, and not in line with the talloc approach of the rest of
the codebase.

I agree that it's a little awkward, but i think there's something of an
impedance mismatch between gmime's object interface and notmuch's use of
talloc and friends.

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1030 bytes --]

  reply	other threads:[~2012-05-18 20:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 17:32 [PATCH v2 0/5] cli: improve handling of crypto parameters and contexts Jameson Graef Rollins
2012-05-18 17:32 ` [PATCH v2 1/5] cli: new crypto structure to store crypto contexts and parameters Jameson Graef Rollins
2012-05-18 17:32   ` [PATCH v2 2/5] cli: modify mime_node_open to take crypto struct as argument Jameson Graef Rollins
2012-05-18 17:32     ` [PATCH v2 3/5] cli: modify mime_node_context to use the new notmuch_crypto_t Jameson Graef Rollins
2012-05-18 17:32       ` [PATCH v2 4/5] cli: new crypto verify flag to handle verification Jameson Graef Rollins
2012-05-18 17:32         ` [PATCH v2 5/5] cli: lazily create the crypto gpg context only when needed Jameson Graef Rollins
2012-05-18 19:21           ` Austin Clements
2012-05-18 19:45             ` Jameson Graef Rollins
2012-05-18 20:37               ` Daniel Kahn Gillmor [this message]
2012-05-18 20:42                 ` Jameson Graef Rollins
2012-05-19 11:26         ` [PATCH v2 4/5] cli: new crypto verify flag to handle verification Jani Nikula
2012-05-19 16:28           ` Jameson Graef Rollins
2012-05-18 19:09       ` [PATCH v2 3/5] cli: modify mime_node_context to use the new notmuch_crypto_t Austin Clements
2012-05-18 19:17         ` Jameson Graef Rollins

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

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB6B2F5.6090105@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=notmuch@notmuchmail.org \
    /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 public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).