Yes, I use pthreads on Windows. Since you stated "How would you handle TSD,
for example? There is no *portable* way to hook the destruction of a
thread." I figured you were dismissing pthreads as non-portable due to it
not being natively available on Windows, and accepted that you were only
interested in native threading. You may have forgotten about:
int pthread_key_create(pthread_key_t *key, void
(*destructor)(void*));
There are so many things that can't be done portably.
Daemons/Windows-services, sockets/winsock, drive/mount enumeration, GUIs(!),
etc. I don't give these a low priority just because there are system
specifics involved. Check out all of the #if's in OpenSSL; the crypto/rand
code for starters. It would be nice to write pure POSIX code that works
across all platforms but in reality how often is this possible for anything
other than a trivial app? Encapsulating system specifics is a perfectly
reasonable compromise, and the same can obviously be done for threading and
dynamic library management. Pthread-win32 is of course such a library.
I don't know that repeatedly loading and unloading DLLs is unusal. Sure,
doing so constantly would be weird, but I've already stated that the example
I presented was extreme in order to illustrate the point that we are talking
about a leak. Good point, if OpenSSL was documented to not support being
dynamically loaded/unloaded/reloaded then my argument would be moot, but I
don't believe it is documented, so arguing over this is a religious war at
best. It seems that you've not needed to dynamically load/unload/reload
DLLs, but believe me, there are scenarios where it needs to be done. And
when you do, this leak quacks like a leak.
Steven
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Wednesday, 16 November 2005 5:46 PM
To: openssl-users@openssl.org
Subject: RE: SSL_library_init - missing 36 bytes after cleanup
> There may be no portable way to handle TSD cleanup, but there is no
> portable way to do threading at all anyway, so I'm not sure what your
> argument is there.
Huh? POSIX threads are portable. There are even support libraries
for WIN32.
> I'm not arguing that any of this needs to be done in a portable way,
> and of course it cannot be since dynamically loadable modules (and
> threading) are outside the scope of the C standard.
Well, that's the problem. When you're trying to maintain a portable
library, doing things that can't be done portably gets a low priority. It is
often a better choice just not to do them.
> My original response
> was to correct your reply to Steffen in which you stated that these 36
> bytes are not leaked. The fact is that they are. Perhaps it's not a
> serious leak, but a leak nonetheless.
They are leaked only if a program repeatedly opens and closes the
OpenSSL library. If this is not supported, then they are only leaked if the
library's interface contract is broken.
I don't know if OpenSSL is supposed to specifically support the
unusual use of being dynamically linked, and repeatedly opened and closed. A
leak that only occurs under unsupported usage is not a leak if only
supported usage is attempted.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
