cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: timeouts and multithreading

From: Lucas Adamski <wakked1_at_yahoo.com>
Date: Fri, 21 Sep 2001 10:45:10 -0700

After digging around into multithreading stuff, I came across ZThreads,
which is a C++ lib (unfortunately I guess) for solves a lot of these
problems in a multithreaded environment, as it provides abstractions such
as queues and pipes. A simpler solution for just the pipe is just to wrap
it in a mutex, but that may in fact end up slowing things down if you run a
program with a lot of threads, if a lot of them are stuck waiting for the
mutex versus doing their own lookups?
  Lucas.

-----Original Message-----
From: curl-library-admin_at_lists.sourceforge.net
[mailto:curl-library-admin_at_lists.sourceforge.net]On Behalf Of Bjorn
Reese
Sent: Thursday, September 20, 2001 12:04 PM
To: Libcurl
Subject: Re: timeouts and multithreading

Daniel Stenberg wrote:

> The connection should be rewritten to use non-blocking connect to avoid
the
> need for signals.

Fortunately, this is not so difficult to do (although it is not
entirely straight-forward). The late Triacle contains working non-
blocking connect code. The major problem is handling the error codes
correctly across the various platforms.

> The name resolving could be rewritten using an asynchronous name resolver
> that would be possible to abort without signals. This would take some
effort
> to make it work neatly on many platforms.

Which reminds me... :)

I had a look at replacing the signals with non-blocking name resolving.
The basic idea is to spawn a separate process to perform the blocking
name resolving and send the data back to the original process through
a pipe. As we can do non-blocking reads/writes on the pipe, the original
process can proceded with other tasks while the other process resolves
the name.

Triacle (again) contains working code for this, and I was looking at
integrating this into libcurl. The reason I haven't done so yet (apart
from the usualy time pressure) is that it introduces another problem.
What happens if two threads reads from, or writes to, the pipe at the
same time? Because we are using some kind of shared resource, we must
provide synchronization in multi-threaded environments.

Btw, I do not expect to have much time for this (especially since I
would have to spend time re-acquainting myself with the libcurl code),
nor do I have a need for multi-thread safe code, but I would gladly
provide examples, hints, and feedback if anybody wishes to give it a
try.
Received on 2001-09-21