On Fri, 15 Feb 2002, Giaslas Georgios wrote:

> i'm using libcurl on a linux pc box with a multithreaded application, where
> every thread makes http requests. I use both the options CURLOPT_TIMEOUT
> and CURLOPT_CONNECTTIMEOUT, although the man page says that they doesn't
> work on unix multithreaded systems. In linux, (i think) when a connection
> or a transfer times out the signal is delivered only to the thread that
> caused the timeout.

That might be the case for Linux, I don't know. Signals are not generally
suitable as a mechanism for events when multiple threads are in use.

Signals are the only (current) way we can abort name resolve calls (on
unix-like systems), so we use alarm() to get a signal after X seconds.

> Indeed, my application works alright with a small number of threads (below
> 100). However, i experience a problem with a large number of threads (above
> 100). Some threads don't timeout, so the application never ends because the
> master thread waits for all of them to join.

So why don't they timeout, do you know?

> How do you handle the transfer and connection timeouts? Can you help me
> with this?

What is the problem in the first place? Why do you need timeouts at all?
Won't the timeouts together with some suitable values for
CURLOPT_LOW_SPEED_LIMIT and CURLOPT_LOW_SPEED_TIME be enough?

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/