[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v1 RFC 08/34] crypto: introduce new module for c
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v1 RFC 08/34] crypto: introduce new module for computing hash digests |
Date: |
Wed, 13 May 2015 19:12:32 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
On 13/05/2015 19:04, Daniel P. Berrange wrote:
> I'm thinking perhaps a better approach could be for the crypto related
> APIs to call qcrypto_init() on an as-needed basis. The downside would
> be that this could delay the point at which the user sees a gnutls
> initialization failure to only after QEMU has been running for a while,
> instead of being upfront at startup. The plus side is obviously that
> we'd not need to update every binary program main() method.
>
> I notice though that QEMU does not make use of pthread_once() for
> global initializers. Is there any particular reason for this ? With
> this crypto code it is not safe to rely on being single threaded,
> since the crypto code can be invoked from I/O threads as well as
> the main event loop. So ideally I would use a pthread_once() instead
> of having a static 'bool is_initialized' protected by a pthread_mutex
Yes---though you'd use a GOnce instead for portability.
In fact you would likely keep both, and use a GOnce from qcrypto_init.
Then you can always call qcrypto_init from main if that helps making
early failures clearer.
Paolo