Sorry forgot to change a couple of bits in here:

This is from a library I have written which has the following in the
headers:

#define NO 0
#define YES 1
#define SUCCESS 0
#define FAILED -1

Thanks
Andy

On Fri, 2004-11-19 at 09:17, Andy Hobbs wrote:
> Hi,
>
> have a look at the attached C module, you are welcome to use this.
>
> You will need to change the includes to suit your needs.
>
> The apache httpd sources are a good place to look for this sort of thing
> as they have done it very well
>
> hope this helps
>
> Andy
>
>
> On Fri, 2004-11-19 at 06:48, hzhijun wrote:
> > Hi, Frank
> > I really a newbie to the OpenSSL callback usage. If I set the locak callback,
> > What should be done in the callback function?
> > Thanks
> >
> > > hzhijun wrote:
> > > > i don't think it need to set locking_function since i did not use any shared datastructures in my application.
> > > you may not, but the OpenSSL-LIB does definitly. And as soon as your
> > > application gets multithreaded, you always risk a race conditions which
> > > not neccessarily could cause a crash, but which could.
> > >
> > > Although OpenSSL uses many global data structures, all i have to do is
> > > use the proper compiler to build OpenSSL with multithread options.
> > > ...for having it built with multithread-supprt this is sufficient, but
> > > as soon as you know your application gets multithreaded (whether you
> > > spawn threads by your own or you use some library-functions which does
> > > this for you (implicitly)...for example using the multi-interface from
> > > libcurl should be enough) it is a must to "give" the OpenSSL-Lib the
> > > callbacks to be able to lock their global datastructures, nevertheless
> > > your app would work without the locks very often or even nearly always,
> > > it is not relieable and not a good way to code. You probably/hopefully
> > > would use locking mechanism to protect data-access to your global
> > > datastrucutres if you would had some in *your* multithreaded
> > > application. Just because you dont't see the library's code which spawns
> > > threads and makes accesses to global data from this threads, it ist no
> > > good idea not to lock the accesses. You just risk having the whole
> > > application crashed in some day. And in this day you even might have
> > > forgotten about the locking issue, so I predict you wont' find the cause
> > > or even some indicators for it.
> > >
> > > Anyway, best wishes. If you need some help on how to provide those
> > > callbacks in a propriate way, just let know.
> > >
> > > Ciao, Frank.

-- 
Andy Hobbs <andy_at_hobbs.uk.net>