From: Dan Kegel [EMAIL PROTECTED]
dank that sense). I have asked for it quite some time ago, see
dank http://www.opeenssl.org/thoughts/MT-mutexes.txt
dank
dank I think you meant
dank http://www.openssl.org/~levitte/thoughts/MT-mutexes.html
Nope, I meant
On Fri, Dec 15, 2000 at 09:05:14AM -0500, Rich Salz wrote:
Please don't try to make objects themselves safe across threads.
We have to. E.g., it is not usual to have multiple threads use SSL
structures created from a single SSL_CTX, and access to this SSL_CTX
and dependent objects (such as
On Sun, Dec 17, 2000 at 04:22:17PM -0800, Dan Kegel wrote:
I think it is a fool's errand to try to make it possible to
"share" every data structure across threads.
Noone has said "every", but some have asked for "some".
And then there are the contrarians who ask for "none".
It ought to
Bodo Moeller wrote:
On Sun, Dec 17, 2000 at 04:22:17PM -0800, Dan Kegel wrote:
I think it is a fool's errand to try to make it possible to
"share" every data structure across threads.
Noone has said "every", but some have asked for "some".
And then there are the contrarians who ask for
From: Dr S N Henson [EMAIL PROTECTED]
drh I can see a couple of ways to handle this. One is to let the callbacks
drh handle everything: add an extra argument that passes the address of the
drh structure associated with the lock and let them use it as an opaque ID
drh and handle a lock pool as it
From: Rich Salz [EMAIL PROTECTED]
rsalz What is the problem you are trying to solve? Who has asked for it?
The problems is operations on one object locking out operations on
separate objects of the same type (thus making the locking needless in
that sense). I have asked for it quite some time
Richard Levitte - VMS Whacker wrote:
rsalz What is the problem you are trying to solve? Who has asked for it?
The problems is operations on one object locking out operations on
separate objects of the same type (thus making the locking needless in
that sense). I have asked for it quite
To play devil's advocate, why don't we get rid of all locks in OpenSSL?
Because, as we found out (back when my team first contributed the locking code
to SSLeay), if you only have the granularity of a single "openssl lock", then
only a single thread can do SSL_write. That locking hierarchy is
Rich Salz wrote:
To play devil's advocate, why don't we get rid of all locks in OpenSSL?
Because, as we found out (back when my team first contributed the locking code
to SSLeay), if you only have the granularity of a single "openssl lock", then
only a single thread can do SSL_write.
From: Rich Salz [EMAIL PROTECTED]
rsalz structure itself. I'd do a malloc(size_of_mutex() + sizeof(RSA)) and
rsalz return a pointer to the RSA part of that blob. I haven't thought
rsalz through everything yet.
rsalz
rsalz You can't do that; pthreads, for example, often implement the
rsalz
You can still do it and keep opaque refs and associate locking at the class *or object* level:
typedef void *TOpaque;
typedef struct
{
int spin;
void *mem;
int size;
} TMutex;
typepdef struct/* Use this as the header for all lockable classes */
{
I think we should handle this such that an application can provide
either global "type" locks (as at present) or structure based locks.
Then the application can decide whichever is more appropriate to the
environment in question.
I can see a couple of ways to handle this. One is to let the
What is the problem you are trying to solve? Who has asked for it?
I think it is a fool's errand to try to make it possible to "share" every data
structure across threads. You can't get it exactly right, you need
higher-level information that is in the application, not at the OpenSSL
level.
Rich Salz wrote:
What is the problem you are trying to solve? Who has asked for it?
Inquiring minds want to know.
To play devil's advocate, why don't we get rid of all locks in OpenSSL?
Let's say we split OpenSSL into the classic API, which would consist of
a wrapper that was careful to lock
I agree. 100%.
On Sat, Dec 16, 2000 at 07:39:29PM -0800, Dan Kegel wrote:
Rich Salz wrote:
What is the problem you are trying to solve? Who has asked for it?
Inquiring minds want to know.
To play devil's advocate, why don't we get rid of all locks in OpenSSL?
Let's say we split
What I'd like to know is if the following structures are basically
just a memory blob with some bits that are fiddled with, or if it's a
handle to some bulkier resource. It's probably OK to create, say,
1 of the former without ay problem, the latter would create
problems in those
You forget about threads sharing some objects on the heap. There was
a patch a few days ago about locking a little more around some RSA
operations...
Oh gosh, no, don't do that!
Please don't try to make objects themselves safe across threads.
/r$
Arne Ansper wrote:
Toomas Kiisk ([EMAIL PROTECTED]) reported that he was able to create more
than 300 000 unnamed mutexes without problems.
Creating numerous mutexes is not a problem: cycling them through and
thrashing memory is. The problem with the implementation of mutexes is
the fact
Richard Levitte - VMS Whacker wrote:
Using dynamic locks would create fragmentation of the heap, but there
are solutions to that, to some level of intricacy. However, there's
something else that disturbs me a bit, and it's the thought that locks
may be a limited resource and can't therefore
From: Sean Walton [EMAIL PROTECTED]
swalton Arne Ansper wrote:
swalton
swalton Toomas Kiisk ([EMAIL PROTECTED]) reported that he was able to create more
swalton than 300 000 unnamed mutexes without problems.
swalton
swalton Creating numerous mutexes is not a problem: cycling them
swalton
From: Sean Walton [EMAIL PROTECTED]
swalton You could a centralized locking system instead of heap.
swalton Imagine creating a custom mutex table that is fixed (or even
swalton dynamic). As each mutex is allocated and freed, it would
swalton come from this space. Since it is centralized, it
structure itself. I'd do a malloc(size_of_mutex() + sizeof(RSA)) and
return a pointer to the RSA part of that blob. I haven't thought
through everything yet.
You can't do that; pthreads, for example, often implement the mutex as an
opaque pointers.
/r$
As has been mentioned before, I've given some thought to having
thread-locks with a higher granularity than we have today. As it is
now, the locking is done at type level (class level for the OO
fanatics). This means that if some thread locks CRYPTO_LOCK_RSA, all
operations that need to lock
From: Rich Salz [EMAIL PROTECTED]
rsalz It's probably OK to create, say,
rsalz 1 of the former without ay problem, the latter would create
rsalz problems in those quantities:
rsalz
rsalz 10,000 locks? That concerns me.
I did exagerate a bit, but I see the possibility in big-scale SSL
24 matches
Mail list logo
