On Thu, Aug 14, 2008 at 10:04 PM, Sander Temme [EMAIL PROTECTED] wrote:
Folks,
The following patch against trunk adds dynamic locking callbacks to mod_ssl.
OpenSSL uses these in several places, including the CHIL engine that
interfaces with the nCipher products. I work at nCipher, and this
On Wed, Aug 20, 2008 at 10:36:37AM -0400, Sander Temme wrote:
On Aug 18, 2008, at 5:18 AM, Joe Orton wrote:
So generally pconf is the right pool to use, along with a cleanup
registered against that pool which sets the callbacks to NULL.
Yes, with the cleanup it no longer hangs. What about
-Ursprüngliche Nachricht-
Von: Joe Orton
Gesendet: Donnerstag, 21. August 2008 13:41
An: dev@httpd.apache.org
Betreff: Re: [PATCH] Dynamic locking upcalls in mod_ssl
On Wed, Aug 20, 2008 at 10:36:37AM -0400, Sander Temme wrote:
On Aug 18, 2008, at 5:18 AM, Joe Orton wrote
On Thu, Aug 21, 2008 at 01:49:35PM +0200, Plüm, Rüdiger, VF-Group wrote:
Given that the lifetime of the callbacks is now constrained, is the
new global pool still needed?
Where does this patch use a global pool? It keeps a reference on the pconf
pool in a global variable, but it no longer
On Aug 21, 2008, at 7:41 AM, Joe Orton wrote:
Yes, with the cleanup it no longer hangs. What about stashing a pool
reference in a global, is that a red flag?
Given that the lifetime of the callbacks is now constrained, is the
new
global pool still needed?
As Rüdiger mentioned, the pool
On Aug 18, 2008, at 5:18 AM, Joe Orton wrote:
So generally pconf is the right pool to use, along with a cleanup
registered against that pool which sets the callbacks to NULL.
Yes, with the cleanup it no longer hangs. What about stashing a pool
reference in a global, is that a red flag?
-Ursprüngliche Nachricht-
Von: Sander Temme
Gesendet: Mittwoch, 20. August 2008 16:37
An: dev@httpd.apache.org
Cc: Joe Orton
Betreff: Re: [PATCH] Dynamic locking upcalls in mod_ssl
Index: modules/ssl/ssl_util.c
On Aug 20, 2008, at 11:56 AM, Plüm, Rüdiger, VF-Group wrote:
You should set dynlockpool to NULL here as well. In case it is used
afterwards
things segfault and are easier to detected than when an invalid
pointer is used.
This should basicly address your question regarding the reference on
On Fri, Aug 15, 2008 at 06:33:21AM -0700, Sander Temme wrote:
On Aug 15, 2008, at 12:48 AM, Plüm, Rüdiger, VF-Group wrote:
1. Why creating a global pool for dynlockpool? Why can't this be a
subpool
of the pool passed to ssl_util_thread_setup?
Because that's the pconf pool and gets
-Ursprüngliche Nachricht-
Von: Sander Temme
Gesendet: Freitag, 15. August 2008 07:04
An: dev@httpd.apache.org
Betreff: [PATCH] Dynamic locking upcalls in mod_ssl
Folks,
The following patch against trunk adds dynamic locking callbacks to
mod_ssl. OpenSSL uses
On Aug 15, 2008, at 12:48 AM, Plüm, Rüdiger, VF-Group wrote:
1. Why creating a global pool for dynlockpool? Why can't this be a
subpool
of the pool passed to ssl_util_thread_setup?
Because that's the pconf pool and gets cleared across the lifetime of
some of the mutexes that OpenSSL
Folks,
The following patch against trunk adds dynamic locking callbacks to
mod_ssl. OpenSSL uses these in several places, including the CHIL
engine that interfaces with the nCipher products. I work at nCipher,
and this patch makes the CHIL engine load into a stock, unpatched
openssl
12 matches
Mail list logo