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-20