[asterisk-dev] question about asterisk 1.4, func_curl.c, and close_wait state

Paul Albrecht albrecht at glccom.com
Mon Feb 28 15:06:29 CST 2011


On Mon, 2011-02-28 at 14:14 -0600, Tilghman Lesher wrote:
> On Monday 28 February 2011 13:59:47 you wrote:
> > On Mon, 2011-02-28 at 13:32 -0600, Tilghman Lesher wrote:
> > > On Monday 28 February 2011 13:26:35 you wrote:
> > > > On Mon, 2011-02-28 at 13:11 -0600, Tilghman Lesher wrote:
> > > > > On Monday 28 February 2011 11:08:38 Paul Albrecht wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Why does the curl function leave the request connection in the
> > > > > > close_wait state until the channel thread terminates?
> > > > > 
> > > > > That's a question for the libcurl authors, as we use that library
> > > > > for the main functionality.
> > > > 
> > > > Think the curl library default is keepalive and that's a bad thing
> > > > because the socket file descriptor doesn't go away until the channel
> > > > thread terminates. So my question really is does it make sense for
> > > > asterisk to use the library default?
> > > 
> > > We accept patches.  :-)
> > 
> > I "fixed" the problem by hacking the function to call the curl library
> > initialization and cleanup routines each time it's invoked which works
> > for me because there's only one curl request per caller in my
> > application.
> > 
> > Not sure that's the optimal solution for other applications, but I doubt
> > the extra library calls makes much difference for most applications.
> 
> Those initialization and cleanup routines are globals: they are not
> threadsafe.  If you should call one of them while another thread is
> attempting to use the library, bad things will happen.
> 

Not making much sense here ... if the curl library isn't thread safe
then the existing implementation wouldn't work. In my hack, I hold the
curl handle in a local variable so I don't need asterisk thread specific
storage.

-- 
Paul Albrecht




More information about the asterisk-dev mailing list