serf+ssl+threads=trouble

[GoogleCodeExporter]

As far as I can tell, serf doesn't care if it's in a threaded environment
or not.  However, openssl does care, and can  cause problems if it isn't
told how to handle locks.  http://www.openssl.org/docs/crypto/threads.html

Neon sets up openssl lock handling (see ne_openssl.c), but serf doesn't.  

Serf should either match neon, or document the fact that it requires the
application to handle configuring locking for openssl.

-Dan C

Original issue reported on code.google.com by DanChris...@gmail.com on 12 Jun 2007 at 12:07

[GoogleCodeExporter]

Try the attached - this has sat in my tree for a while, but nothing has ever 
needed
threading with serf.

FWIW, this is based on how we did it for flood (a predecessor in a lot of ways 
to serf).

If it looks good, I'll commit a variant of it to trunk.

Original comment by justin.e...@gmail.com on 12 Jun 2007 at 6:01

• Changed state: Accepted

Attachments:

• ssl-locks.patch

[GoogleCodeExporter]

The patch applies fine and seems to work.  I don't have a clean test case, so I 
just
run it and make sure it doesn't cause any regressions.

I admit it, I push subversion harder than most.  I'm using threads in the mstone
module to simulate multiple clients at once.  Each thread is completely 
separate, but
that doesn't stop openssl from sharing things underneath it.

-Dan C

Original comment by DanChris...@gmail.com on 12 Jun 2007 at 5:07

[GoogleCodeExporter]

Applied in r1113.

Original comment by justin.e...@gmail.com on 19 Jun 2007 at 12:06

• Changed state: Fixed