On Fri, 2010-06-25 at 21:43 +0100, Darryl Miles wrote:
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from the application. libraries cannot safely setup the
locking
On Mon, 2010-06-28 at 12:25 +0200, Mark Phalan wrote:
On Fri, 2010-06-25 at 21:43 +0100, Darryl Miles wrote:
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from
Guess I replied too quickly... I see why you thought I was spreading
misinformation. Of course I agree that every library could be modified
to use atomic instructions available on their CPU to synchronize. Its
just a lot of modifications to be made considering the vast amount of
code out
On Mon, 2010-06-28 at 07:06 -0700, David Schwartz wrote:
Guess I replied too quickly... I see why you thought I was spreading
misinformation. Of course I agree that every library could be modified
to use atomic instructions available on their CPU to synchronize. Its
just a lot of
David Schwartz wrote:
Actually, that wouldn't work. What if you're using a threading library that
permits threads to run in different SMP domains? In that case, the atomic
instructions would only synchronize between threads running in the same SMP
domain.
As I hinted in another post, the less
Subject:RE: [openssl.org #2293] OpenSSL dependence on external threading
functions is a critical
Darryl Miles wrote:
David Schwartz wrote:
Actually, that wouldn't work. What if you're using a threading
library that
permits threads to run in different SMP domains? In that case, the
atomic
instructions would only synchronize between threads running in the
same SMP
domain.
As
of quality control, in spite of any
disclaimer.
-Original Message-
From: owner-openssl-...@openssl.org on behalf of David Schwartz
Sent: Mon 6/28/2010 6:45 PM
To: openssl-dev@openssl.org
Subject: RE: [openssl.org #2293] OpenSSL dependence on external threading
functions is a critical design
Rene Hollan wrote:
And how, pray tell, should OpenSSL know the threading model the
application uses?
Unless I'm missing something, it strikes me as perfectly reasonable for
OpenSSL to require a reasonable threading API to implement SSL data
integrity, and for the application to provide an
On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
bad things happen and the
dependence on external threading
functions is a critical design flaw
Rene Hollan wrote:
And how, pray tell, should OpenSSL know the threading model the
application uses?
Unless I'm missing something, it strikes me as perfectly reasonable for
OpenSSL to require a reasonable threading API
] OpenSSL dependence on external threading
functions is a critical design flaw
On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
As you said so yourself, and I quote: When both an application and a
library ([...]) both
On Jun 24, 2010, at 4:58 PM, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
I won't get into a personal attack.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
environment.
-Original Message-
From: owner-openssl-...@openssl.org on behalf of Mark Phalan
Sent: Fri 6/25/2010 5:20 AM
To: openssl-dev@openssl.org
Cc: msw...@apple.com
Subject: Re: [openssl.org #2293] OpenSSL dependence on external threading
functions is a critical design flaw
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from the application. libraries cannot safely setup the
locking callbacks.
Just to make it clear why this is a problem imagine
And how, pray tell, should OpenSSL know the threading model the application
uses?
Unless I'm missing something, it strikes me as perfectly reasonable for OpenSSL
to require a reasonable threading API to implement SSL data integrity, and
for the application to provide an implementation that
The only critical bit here is opinion replacing analysis.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
bad things happen and the application can crash.)
Indeed. Spot on, I'd say.
That is /exactly/
On Jun 24, 2010, at 4:58 PM, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
I won't get into a personal attack.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
18 matches
Mail list logo
