On Fri, Nov 30, 2012 at 1:42 PM, Jeffrey Walton wrote:
> On Fri, Nov 30, 2012 at 12:24 PM, NuSkooler wrote:
>> I think responses like this would be much more helpful without the FUD.
> I have no fear since I don't suffer uncertainty. The macros are broken.
>
>> WaitForSingleObject() and WaitForMu
On Fri, Nov 30, 2012 at 12:24 PM, NuSkooler wrote:
> I think responses like this would be much more helpful without the FUD.
I have no fear since I don't suffer uncertainty. The macros are broken.
> WaitForSingleObject() and WaitForMultipleObjects() return WAIT_ABANDONED if
> the mutex has been c
On 11/30/2012 6:24 PM, NuSkooler wrote:
I think responses like this would be much more helpful without the FUD.
WaitForSingleObject() and WaitForMultipleObjects() return
*WAIT_ABANDONED *if the mutex has been closed. WAIT_OBJECT_0 would only
be expected if you didn't read the documentation. I su
I think responses like this would be much more helpful without the FUD.
WaitForSingleObject() and WaitForMultipleObjects() return *WAIT_ABANDONED *if
the mutex has been closed. WAIT_OBJECT_0 would only be expected if you
didn't read the documentation. I suggest you both do so before utilizing
thes
On Thu, Nov 29, 2012 at 9:57 AM, Staneva, Yana wrote:
> Help please.
>
> I have a Win32 application (service) that loads several dlls that make
> OpenSSL calls. Also there is a separate dll that takes care of the OpenSSL
> initialization (thread setup, SSL_library_init(), SSL_CTX_new() ).
>
> I’ve
Help please.
I have a Win32 application (service) that loads several dlls that make OpenSSL
calls. Also there is a separate dll that takes care of the OpenSSL
initialization (thread setup, SSL_library_init(), SSL_CTX_new() ).
I've followed the samples online on how to do the thread setup, so I h
See http://openssl.org/support/faq.html#PROG1 and
http://openssl.org/docs/crypto/threads.html
--
"The World is a book, and those who do not travel read only a page." -
St. Augustine.
__
OpenSSL Project
Hi,
I am using OpenSSL-1.0.0g in a multithreaded environment. Each thread comes up
with its own decryption context (which has own decrypted premaster, the random
values and rsa pointer). And I am sure NO two threads touch each other's
decryption context.
But I see some issue (program crash) wh
Sorry, I meant the SSL_CTX initialization code.
--
FrÃdÃric Giudicelli
http://www.newpki.org
Alberto Alonso wrote:
Changing the code to use one SSL_CTX per thread is a large
task because of the complexity of the whole system.
The initialization code is probably easier to look at:
I use:
extern
Changing the code to use one SSL_CTX per thread is a large
task because of the complexity of the whole system.
The initialization code is probably easier to look at:
I use:
extern pthread_mutex_t *ggsyscom_ssllock_cs;
extern long *ggsyscom_ssllock_count;
which are defined on the main.c file as
I assume Stephen mentionned EVP_CIPHER_CTX because he wasn't sure which
"ctx" you were talking about.
I can garantee you that shared SSL_CTX work fine, as long as the mutexes
are initialized the proper way.
Did you try to use one SSL_CTX per thread to see if it worked ? If you
have a problem wit
Actually I already initialize the locking callbacks. What got me
confused is the EVP_CIPHER_CTX stuff as I have never seen that.
Thanks,
Alberto
On Fri, 2004-02-20 at 17:33, FrÃdÃric Giudicelli wrote:
> If you share the return of the SSL_CTX_new call, then you need to
> initialize the mutexes
If you share the return of the SSL_CTX_new call, then you need to
initialize the mutexes in libcrypto, see CRYPTO_set_locking_callback for
this.
The second option is to have one SSL_CTX per thread, as mentionned by
Stephen.
Regards,
--
Frédéric Giudicelli
http://www.newpki.org
Alberto Alonso wr
On Fri, 2004-02-20 at 16:34, Dr. Stephen Henson wrote:
> Looks like a race condition of some sort.
>
> Well first thing I'd suggest is using the latest 0.9.7 snapshot and seeing if
> you still have the problem.
I will try that.
>
> Also compile OpenSSL with debugging symbols so the precise loca
On Fri, Feb 20, 2004, Alberto Alonso wrote:
> I'm trying to use openssl-0.9.7a-23 (the RPM from Fedora 1)
> in a multithreaded environment.
>
> Basically I have a server with about 5 worker threads and
> a client with a varying number of threads that connect to
> the server.
>
> When using arou
I'm trying to use openssl-0.9.7a-23 (the RPM from Fedora 1)
in a multithreaded environment.
Basically I have a server with about 5 worker threads and
a client with a varying number of threads that connect to
the server.
When using around 20 threads at the client I can't see any
problems.
But w
16 matches
Mail list logo
