Re: [openssl-dev] [openssl-commits] UI_METHOD

[Richard Levitte]

In message <9da4cbdc-7437-b942-0d2e-e05808cd1...@akamai.com> on Thu, 12 Jan 
2017 11:17:10 -0600, Benjamin Kaduk  said:

bkaduk> On 01/11/2017 11:27 AM, Richard Levitte wrote:
bkaduk> 
bkaduk> The branch master has been updated
bkaduk>via  66ed24b1624606593a23c9fe78d459718d26409c (commit)
bkaduk>via  78b19e90b4aade1ffdf8d918277910b01dac1d76 (commit)
bkaduk>via  cc10f2275594eac2bcdaa218c1d6f672c2b891b7 (commit)
bkaduk>via  3ab3c8cb274aca1b5c0fbf83af96e49baf422708 (commit)
bkaduk>via  0fe1fc858a0519c3866c0d2e88513e677b674926 (commit)
bkaduk>via  18cfc668eae2c296e9bc90ffc989d9bbe61cc82f (commit)
bkaduk>via  a223ffe6d35209c59ed498ee89d1bac6e82e2ac2 (commit)
bkaduk>via  264b2d92511572a247ecb673d61ff385deb9eb8d (commit)
bkaduk>   from  5eeb6c6e562937dcfdd4b79619a699a118deadba (commit)
bkaduk> 
bkaduk> +static int ui_method_data_index()
bkaduk> +{
bkaduk> +static int idx = -1;
bkaduk> +
bkaduk> +if (idx == -1)
bkaduk> +idx = CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_UI_METHOD,
bkaduk> +  0, NULL,
bkaduk> +  ui_new_method_data,
bkaduk> +  ui_dup_method_data,
bkaduk> +  ui_free_method_data);
bkaduk> 
bkaduk> Should this have some synchronization around it to prevent concurrent
bkaduk> checks in multiple threads? It looks like we use a lock for our
bkaduk> internal stuff, but a run_once ought to be fine, too.

Good point...  and quite easily done.

Incidently, include/internal/thread_once.h isn't telling the truth
about the return value of RUN_ONCE...  I'll take advantage of that!

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-commits] UI_METHOD

[Benjamin Kaduk]

On 01/11/2017 11:27 AM, Richard Levitte wrote:
> The branch master has been updated
>via  66ed24b1624606593a23c9fe78d459718d26409c (commit)
>via  78b19e90b4aade1ffdf8d918277910b01dac1d76 (commit)
>via  cc10f2275594eac2bcdaa218c1d6f672c2b891b7 (commit)
>via  3ab3c8cb274aca1b5c0fbf83af96e49baf422708 (commit)
>via  0fe1fc858a0519c3866c0d2e88513e677b674926 (commit)
>via  18cfc668eae2c296e9bc90ffc989d9bbe61cc82f (commit)
>via  a223ffe6d35209c59ed498ee89d1bac6e82e2ac2 (commit)
>via  264b2d92511572a247ecb673d61ff385deb9eb8d (commit)
>   from  5eeb6c6e562937dcfdd4b79619a699a118deadba (commit)

> +static int ui_method_data_index()
> +{
> +static int idx = -1;
> +
> +if (idx == -1)
> +idx = CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_UI_METHOD,
> +  0, NULL,
> +  ui_new_method_data,
> +  ui_dup_method_data,
> +  ui_free_method_data);

Should this have some synchronization around it to prevent concurrent
checks in multiple threads?  It looks like we use a lock for our
internal stuff, but a run_once ought to be fine, too.

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev