All,
David cam up with a solution that looks to me as some thing that would be really nice, he suggested that OpenSSL would allow the developer to register a callback function to do the unsafe functions.
However while he thinks OpenSSL should default to the OS 'best' function available, I am not sure, could be that it still could be good to have at least the OpenSSL functions clean with mutex.
Q. What do we (Me or some one else) needs to do to get this callback function thing rolling into the CVS?
Joe
On 8/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi,
> >why not use mutexes to wrap the gmtime and memcpy,
> >like other places in the library?
>
> Because it is either needless or insufficient.
(snipp)
> On platforms where thread-specific
> data is not used, the mutexes would not prevent other code (not part of
> OpenSSL) from calling these functions in-between when OpenSSL calls them and
> when the returned data can be used or copied.
Well, while it is still insufficient, mutexes would allow a user calling
OpenSSL functions from multiple threads to do so without having to worry about
all the internals, like "do function a() and b() both use gmtime internally,
so a common mutex around those two function calls is needed?" Not to mention
that in a cross-platform application it's going to be needed on a few platforms
only, while on most it will work without them. Ensures interesting testing and
debugging sessions, IMO.
Of course, if the user is calling gmtime himself, he still needs to know such
stuff, but that might be less common than calling two openssl functions that
end up calling gmtime. Also, you could add a warning in such case that any
multi-threaded application needs to wrap their gmtime calls with such and such
mutex.
OTOH, if you have two or more libraries taking this approach, each using a
gmtime wrapper with its own mutex, that's possibly going to be more confusing
than helpful.
Regards,
Stefan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
