headers
Mohun Biswas | 1 Jan 2008 19:23
Favicon

minor bug report: --libcurl output

When --libcurl is used to generate a C program, the main() function is
correctly prototyped as 'int' but there is no return statement -
execution just drops off the end.

MB
Permalink | Reply | 1 comment |
headers
Daniel Stenberg | 1 Jan 2008 22:11
Picon
Favicon
Gravatar

Re: minor bug report: --libcurl output

On Tue, 1 Jan 2008, Mohun Biswas wrote:

> When --libcurl is used to generate a C program, the main() function is 
> correctly prototyped as 'int' but there is no return statement - execution 
> just drops off the end.

Thanks, fixed now!

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 1 Jan 2008 23:04
Picon
Favicon
Gravatar

Re: resolver thread deadlock during Windows DLL attach

On Sun, 30 Dec 2007, Mohun Biswas wrote:

> So the question is: is there a way to get the hostname resolved without 
> spawning a new thread? I've not followed any libcurl DNS discussions in the 
> past because we're at the other end of the spectrum where we only need to 
> resolve one hostname once. In fact I could probably work around this by 
> using a wrapper program to convert it to an IP address and place that in the 
> environment but I'm hoping for a cleaner solution.
>
> I know there's a thing called c-ares but that seems to be going the wrong 
> direction. What I think I need is a *synchronous* resolver that will work in 
> the current thread (but then I don't claim to understand DNS).

In fact, using c-ares would solve your problem and still allow the name 
resolve to get timed out (if you want to). But it would also add another lib 
of course...

The alternative to that, is to make sure USE_THREADING_GETHOSTBYNAME isn't 
defined in lib/setup.h when you build libcurl as then it won't build with a 
threaded resolver but instead use the built-in fallback method: plain 
synchronous lookup with gethostbyname().

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Permalink | Reply | 2 comments |
headers
Andreas Volz | 1 Jan 2008 23:29

Curl from multiple threads and callback functions

Hello,

In my application I generate a dynamic number of download threads. My
problem is the static writer callback. For each CURL handle I would
need a new callback function at compile time. But I know the number of
CURL handles only at runtime. Do you understand my problem? Any ideas
how to solve it?

regards
Andreas
Permalink | Reply | 3 comments |
headers
Dan Fandrich | 2 Jan 2008 00:25
Favicon

Re: Curl from multiple threads and callback functions

On Tue, Jan 01, 2008 at 11:29:43PM +0100, Andreas Volz wrote:
> In my application I generate a dynamic number of download threads. My
> problem is the static writer callback. For each CURL handle I would
> need a new callback function at compile time. But I know the number of
> CURL handles only at runtime. Do you understand my problem? Any ideas
> how to solve it?

I'm afraid I don't understand the problem.  You can set a new callback
function for each handle if you want to, but why do you need to?
You can pass in a unique datum into the static callback using the
CURLOPT_WRITEDATA option, and use that to perform different behaviour
in the callback on a per-handle basis.

>>> Dan
--

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved
Permalink | Reply | 2 comments |
headers
Jamie Lokier | 1 Jan 2008 23:25

Re: resolver thread deadlock during Windows DLL attach

Mohun Biswas wrote:
> So presumably starting a new thread from DllMain isn't allowed. In fact 
> I just found this in MSDN about DllMain:
> 
> "Access to the entry point is serialized by the system on a process-wide 
> basis. Threads in DllMain hold the loader lock so no additional DLLs can 
> be dynamically loaded or initialized."

You have to be very careful with DllMain.  A lot of things don't work
properly from DLL_PROCESS_ATTACH, usually deadlocking but other subtle
bugs are possible too.  (Detaching is even worse).

Unlike modern Unix, where it's safe to do most things during DLL
initialisation and finalisation, because those phases are kept
separate from the actual loading, on Windows it isn't safe.

In particular, initialising Winsock from DllMain doesn't always work
(because it might load some Winsock DLLs), depending on the version of
Windows (and Winsock, and third party network products), so even if
you use an IP address, or _synchronous_ DNS resolution, it's not
guaranteed to work on all Windows versions.

-- Jamie
Permalink | Reply | 1 comment |
headers
Mohun Biswas | 2 Jan 2008 02:09
Favicon

Re: resolver thread deadlock during Windows DLL attach

Daniel Stenberg wrote:

 > The alternative to that, is to make sure USE_THREADING_GETHOSTBYNAME
 > isn't defined in lib/setup.h when you build libcurl as then it won't
 > build with a threaded resolver but instead use the built-in fallback
 > method: plain synchronous lookup with gethostbyname().

Thanks! It did solve the problem (though I'm running into other issues 
along the lines of what Jamie predicted). But my test case which hung in 
the resolver no longer does so. Time to drill in deeper on the other issues.

> In fact, using c-ares would solve your problem and still allow the name 
> resolve to get timed out (if you want to). But it would also add another 
> lib of course...

I tried c-ares last night. I was able to get it built and configure 
libcurl to use it (I think) but the result didn't seem to fix the 
problem. Is there something I need to pass with e.g. curl_easy_setopt() 
or should the simple fact of being configured with ares have fixed it? 
The no-threads answer above is simpler and probably for my case but I'm 
still curious.

MB
Permalink | Reply | 1 comment |
headers
Mohun Biswas | 2 Jan 2008 02:28
Favicon

Re: resolver thread deadlock during Windows DLL attach

Jamie,

> You have to be very careful with DllMain.  A lot of things don't work
> properly from DLL_PROCESS_ATTACH, usually deadlocking but other subtle
> bugs are possible too.  (Detaching is even worse).

Yes, I've read these warnings too. Unfortunately there isn't a lot of 
choice since DLL_PROCESS_ATTACH is the only hook available, so I'm 
hoping to tiptoe through the minefield unscathed.

> In particular, initialising Winsock from DllMain doesn't always work
> (because it might load some Winsock DLLs), depending on the version of
> Windows (and Winsock, and third party network products), so even if
> you use an IP address, or _synchronous_ DNS resolution, it's not
> guaranteed to work on all Windows versions.

Since we're already using a DLL-injection technique, I've been playing 
with the idea of injecting ws2_32.dll first, followed by our DLL. The 
hope is that when our DLL, which in turn uses libcurl, comes along, 
Winsock will be already loaded and initialized. There may still be some 
LoadLibrary calls initiated during our DLL_PROCESS_ATTACH but AIUI if 
the DLL has already been attached to the current process space any 
subsequent LoadLibrary calls are no-ops.

In fact when I first encountered the hang I assumed it was the result of 
loading Winsock from DllMain and wrote up a test case to dig into it. I 
was quite surprised to find out that (a) the hang was in the DNS 
resolver and (b) once that problem was solved (with Daniel's help) the 
test case actually succeeds in establishing an HTTP connection and doing 
a GET from DllMain. Unfortunately even with these fixes the main
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkatraman_S | 2 Jan 2008 05:51
Picon
Favicon

Re: Curl Linux client - windows (w2k3) server GSS

  >> 1. Re: Curl Linux client - windows (w2k3) server GSS

>>On Fri, 28 Dec 2007, Venkatraman_S <at> Dell.com wrote:

>>> But it fails. Any pointers?

>>I'd say there's a clue in the fact that libcurl doesn't seem to send
any 
>>Authorization: header, which indicates that it doesn't activate the
auth at 
>>all. Which is weird.

>>What libcurl version is this and is it built with GSS-Negotiate
enabled?

curl 7.17.1 (x86_64-unknown-linux-gnu) libcurl/7.17.1 OpenSSL/0.9.8a
zlib/1.2.3 libidn/0.6.0
Protocols: tftp ftp telnet dict http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

>>> Is GSS_Negotiate between Linux to Windows ADS supported?

>>libcurl can be built to support GSS-Negotiate, and when that is
supported it 
>>is used when asked to and the server wants it, it has no relevance at
all if 
>>the server is Windows or ADS or whatever.

>>But sure, there might be a bug lurking in there.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andreas Volz | 2 Jan 2008 09:38

Re: Curl from multiple threads and callback functions

Am Tue, 1 Jan 2008 15:25:05 -0800 schrieb Dan Fandrich:

> On Tue, Jan 01, 2008 at 11:29:43PM +0100, Andreas Volz wrote:
> > In my application I generate a dynamic number of download threads.
> > My problem is the static writer callback. For each CURL handle I
> > would need a new callback function at compile time. But I know the
> > number of CURL handles only at runtime. Do you understand my
> > problem? Any ideas how to solve it?
> 
> I'm afraid I don't understand the problem.  You can set a new callback
> function for each handle if you want to, but why do you need to?
> You can pass in a unique datum into the static callback using the
> CURLOPT_WRITEDATA option, and use that to perform different behaviour
> in the callback on a per-handle basis.

Ok, that is a good idea. Until now I pass only the file handle into the
callback. If I give a struct into the callback it should work. Thanks
for that hint.

I read that curl is thread save, So does curl only call the callback
once the same time if I use curl from multiple threads? Or do I need to
protect the callback with a mutex?

regards
Andreas
Permalink | Reply | 1 comment |

Gmane