Question: anybody ever had the situation of a socket create or send that
freezes all thread for multiples of 10s? (i.e. 10 or 20 or
30–exactly?) Odd, isn’t it? Thanks! [note this is tcp sockets to IP
addresses, not hostnames, so it is most likely not a DNS latency]
-Roger
Roger P. wrote:
Question: anybody ever had the situation of a socket create or send that
freezes all thread for multiples of 10s? (i.e. 10 or 20 or
30–exactly?) Odd, isn’t it? Thanks! [note this is tcp sockets to IP
addresses, not hostnames, so it is most likely not a DNS latency]
-Roger
Does it help if you do
Socket.do_not_reverse_lookup = true
before you start using sockets?
I think that did it! Thank you!
Where is the documentation for this stuff???
I assume that it does a reverse lookup on every socket? If that’s the
case I might put in a request to ruby to only do reverse DNS
when it is requested (lazily)…hmm…
Joel VanderWerf wrote:
Roger P. wrote:
Question: anybody ever had the situation of a socket create or send that
freezes all thread for multiples of 10s? (i.e. 10 or 20 or
30–exactly?) Odd, isn’t it? Thanks! [note this is tcp sockets to IP
addresses, not hostnames, so it is most likely not a DNS latency]
-RogerDoes it help if you do
Socket.do_not_reverse_lookup = true
before you start using sockets?
Roger P. wrote:
I think that did it! Thank you!
Where is the documentation for this stuff???
It is mentioned in the socket section in the Pickaxe (ed. 1 is on-line
somewhere, ed. 2 is worth buying). But if you don’t know what you’re
looking for that doesn’t help…
It’s just one of those gotchas that keeps coming up. A similar one is
Thread.abort_on_exception = true
(otherwise threads die silently on unhandled exceptions).
I assume that it does a reverse lookup on every socket? If that’s the
case I might put in a request to ruby to only do reverse DNS
when it is requested (lazily)…hmm…
IIRC, the reverse lookup only happens if you call something like
sock.addr or sock.peeraddr, and you’ve left Socket.do_not_reverse_lookup
= false.
On Wed, 29 Aug 2007 03:33:04 +0900, Joel VanderWerf
[email protected] wrote:
It’s just one of those gotchas that keeps coming up. A similar one is
Thread.abort_on_exception = true
(otherwise threads die silently on unhandled exceptions).
You don’t always want to do that, since you can recover the unhandled
exception that terminated a thread via Thread#join or Thread#value
and some libraries rely on this.
-mental
Mental G. wrote:
On Wed, 29 Aug 2007 03:33:04 +0900, Joel VanderWerf
It’s just one of those gotchas that keeps coming up. A similar one is
Thread.abort_on_exception = true
(otherwise threads die silently on unhandled exceptions).
You don’t always want to do that, since you can recover the unhandled
exception that terminated a thread via Thread#join or Thread#value
and some libraries rely on this.
Interesting. I suppose I’ve never run into that. It helped me debug
things, mostly, and seemed useful, though I suppose handling exceptions
on join or checking value is another option.
Thanks.
-Roger
-mental
IIRC, the reverse lookup only happens if you call something like
sock.addr or sock.peeraddr, and you’ve left Socket.do_not_reverse_lookup
= false.
And of course I had been. Silly me. Thank you!
-Roger
MenTaLguY wrote:
On Wed, 29 Aug 2007 03:33:04 +0900, Joel VanderWerf [email protected] wrote:
It’s just one of those gotchas that keeps coming up. A similar one is
Thread.abort_on_exception = true
(otherwise threads die silently on unhandled exceptions).
You don’t always want to do that, since you can recover the unhandled
exception that terminated a thread via Thread#join or Thread#value
and some libraries rely on this.
Good point. It’s a global setting, so should be avoided. Better to set
this flag on threads individually using the instance method
#abort_on_exception and do so only in those cases where you don’t use
join or value to propagate the exception to another thread. For example,
it would be a good idea to set this flag for a thread that is expected
to run indefinitely (no other thread is waiting for it to finish). Even
in that case, you might want to wrap the thread’s code in a rescue
clause, if you just want to log the error and let other threads proceed.