-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A global library init function? #266
Comments
this can be done quietly for the user though, right? through init_once and
ref counting?
…On Mon, Jan 23, 2017 at 11:59 PM, Daniel Stenberg ***@***.***> wrote:
(Discussion forked off a sub-thread
<#261 (comment)>
in #261 <#261>)
I think there's case for adding global library init and free functions to
do global (single) initializations and then the corresponding cleanups.
OpenSSL has an initialization that's only necessary to do once per
process, not once per context as we do now. It is even discouraged to get
called without using the OpenSSL mutex locks
<https://wiki.openssl.org/index.php/Library_Initialization> when using
threads, so it is also a reliability concern.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#266>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP5s4cq0tcO8rgHpzkmuNVz5sOBlEFiks5rVMBBgaJpZM4LrI3F>
.
|
It can only be done hidden in a safe manner if protected by a mutex though, and to protect with a mutex we'd need to add a pthread (or equivalent) requirement... |
Mh, is it useful to do this quietly? I think we should involve the user for these steps. |
thread lib seems like an ok requirement to me in 2017.. if you really don't
want it you can build an atomic spinlock for arm and x86 easily enough for
this 1 case and have an architectural dep instead.
…On Tue, Jan 24, 2017 at 8:06 AM, Daniel Stenberg ***@***.***> wrote:
It can only be done hidden in a safe manner if protected by a mutex
though, and to protect with a mutex we'd need to add a pthread (or
equivalent) requirement...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#266 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP5s4lDT2y7nGmFZ7To0gDELW1dgPdIks5rVTJ-gaJpZM4LrI3F>
.
|
the problem with explicit global init is that it doesn't necessarily embed
well into other libraries.. the library can't really tell if it has been
init'd already/concurrently what not..
…On Tue, Jan 24, 2017 at 8:20 AM, Felix Weinrank ***@***.***> wrote:
Mh, is it useful to do this quietly?
I think we should involve the user for these steps.
For example when initializing the usrsctp library, it is possible to set a
UDP encapsulation port.
IMHO this should the configurable by the user.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#266 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP5s9iWA-YgNT-J8XqiwvyJL2-su3eNks5rVTXSgaJpZM4LrI3F>
.
|
It should also be noted that modern OpenSSL (>= 1.1.0) already depends on pthreads itself, so it isn't that far fetched I think. |
If we have it mutex protected, we can have it done silently if not already done explicitly by the user. So we can in fact have it both ways. If we want to. |
(Discussion forked off a sub-thread in #261)
I think there's case for adding global library init and free functions to do global (single) initializations and then the corresponding cleanups.
OpenSSL has an initialization that's only necessary to do once per process, not once per context as we do now. It is even discouraged to get called without using the OpenSSL mutex locks when using threads, so it is also a reliability concern.
The text was updated successfully, but these errors were encountered: