memory leaks

Dirk Stoecker misc at
Thu Jan 12 15:27:05 CET 2006

On Thu, 12 Jan 2006, Marcus Brinkmann wrote:

> On Thu, 2006-01-12 at 10:09 +0100, ZIGLIO, Frediano, VF-IT wrote:
> > - use a session structure to store callbacks and change all API to
> > accept this session. This as you can imagine breaks API, however you can
> > avoid this using a global session and adding new APIs while old one call
> > new one adding global session, something like
> Yes.  We are now talking about a new project, though.  Ie, a major
> rewrite.  Also, you can't just easily separate everything.  You really
> want to share your random pool as much as possible, because otherwise
> you will be entropy drained very quickly.

It's not so much a major rewrite. Only the few calls to global variables 
must be redirect to context-based-calls.

The sharing can be done library internal:
- Only one global variable containing a list of contexts.
- If there is already a context, the shared data is taken from it.
- Only the last freed context releases the stuff.

Thought this again introduces strange memory issues and must be threading 
save. I would prefer seperate contexts. There shouldn't be such a big 
difference if f.e. two plugins in one program use the library or you have 
two programs.

-- (PGP key available)

More information about the Gcrypt-devel mailing list