On Fri, Jun 11, 2004 at 02:58:00PM +0200, [EMAIL PROTECTED] via RT wrote: > > On June 11, 2004 03:00 am, Jack Lloyd via RT wrote: > > Summary: Threaded applications using the AEP engine break badly on > > Linux. > > I see. The problem seems more about the model used by AEP though. Ie. we > could use CRYPTO_thread_id() instead of getpid() (because unless > CRYPTO_set_id_callback() is called, this devolves into getpid() anyway). > I'm looking at the head of CVS right now, so I don't know off the top of > my head about 0.9.7, but the connection-pooling in engines/e_aep.c > suggests that there is thread-safety between use of these pools, so > setting the id_callback() on NPTL to something that has a common return > value between threads but not between processes *should* solve the > problem. That's assuming that p_AEP_Finalize() closes the connection pool > too, otherwise things leak.
That seems reasonable. > Are you able to move to CVS snapshots by any chance? It would make further > discussion of this (and potential changes to the code) easier to manage. No problem. This was just a benchmark/test tool so I could compare OpenSSL against an AEP driver I was writing for another crypto library. > I'd be curious how you get on if you use CRYPTO_set_id_callback() from > your app to detect real process distinctions (ie. returning the same > process id from sibling threads), and to replace the getpid() call in the > AEP engine with CRYPTO_thread_id(). (You're probably better in this case > to change the pid_t types to "unsigned long" too, matching the > CRYPTO_thread_id() prototype.) Hmm... wouldn't this break other uses of CRYPTO_thread_id? Since they would expect this function to return different values for different threads. -J ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
