Török Edvin wrote:
> >> queue_timeout_for_current_thread(timeout)
> >> - when one of the timeouts expire, it either pthread_cancel, or
> >> pthread_kill that thread
> >> - waiting for a timeout doesn't need to use SIGUSR1, you can use
> >> pthread_cond_timedwait, sleep
> >
> >Sounds good, I like it :)
> >That'll work, provided pthread_cond_timedwait() is available.
> >Other threads, not involved, don't have to do anything.
>
> Would you like to implement it too? ;-)

I have no interest in doing it, sorry! :)

> >> >And after all that, I'm not convinced it's safe anyway to interrupt
> >> >DNS resolution at an arbitrary time. How does curl (when
> >> >single-threaded) ensure that it's safe to longjmp from the SIGALRM
> >> >handler interrupting DNS resolution? What happens to file descriptors
> >> >that may have been opened by the resolver code, and resolver data
> >> >structures that might be in a temporary state?
> >>
> >> Good question. Would it be safe to kill a resolver thread?
> >
> >Not portably, I'd guess.
>
> So, what should be done when the timeout expires?

Hence the other question: is it even safe to interrupt the resolver
like that in single-threaded code?

> >Even with pthreads, there is the matter of doing a DNS resolve in one
> >thread, while another thread does fork/exec for some application
> >reason. The fork/exec may inherit file descriptors created
> >temporarily by the resolver. There is no tidy way to handle this in a
> >library.
>
> Use shared memory/message queues for communication and not pipes if
> you don't want the pipe fd leaked. You can also set close-on-exec flag
> on the pipe, so it won't get inherited over execve.

There's a race between getting the pipe fds, and setting the
close-on-exec flag, during which another thread may fork/exec and
inherit those file descriptors. That can only happen in
multi-threaded programs. Fixing it is a pain, requiring every part of
the application (and libraries) that may fork/exec or open fds in any
way, to grab a read/write lock around that window.

-- Jamie
Received on 2006-09-23