Francis Cianfrocca wrote:
> On 9/16/06, Geff Geff <boing / boing.com> wrote:
>  > What was I thinking was the following:  lets consider the case where 
> you
>> try to timeout a HTTP connect with the net/http stuff.  There are
>> already "timeouts" in the HTTP class.  If my timeout times out before
>> the library's timeout, I end up killing the http thread that is watching
>> the tcpconnect thread.  The tcpconnect thread lives on until it's done.
> 
> I haven't read through the net/http code as it relates to this issue,
> but I did read timeout.rb and as Arnaud says, there should be no
> problem. If I may assume that your thread calls timeout on a net/http
> call, which in turn calls timeout on a TCP connect-attempt, then if
> your timeout fires first, you'll kill the thread that is doing the TCP
> connect, because it's the same thread that called net/http. The
> "internal" timer thread is left running. It will hold a memory
> reference to the killed thread, which can hold resources longer than
> you expect, but there's no leak. When the internal timer thread that
> is left running eventually times out, it will try to raise an
> exception on the killed thread, and nothing will happen.

I think if I timeout a timeout that my timeout is killing the "waiter" 
thread.  And since the waiter thread started the TCPconnect attempt 
thread that tcpconnect stays running until it ends, if it ends.  Kinda 
like my sleep thread example.  Is that not accurate?

-- 
Posted via http://www.ruby-forum.com/.