On Thu, Dec 13, 2007 at 04:05:19AM +0900, Andrwrote:

>The auto-update function runs in a different thread, so the user won't
>even notice that the application is checking for a new version.
>
>It all works fine, EXCEPT when there's no network connection. In this
>case, the WHOLE application simply hangs for one or two minutes, with
>no regard for the fact that this code is running in a thread, or that
>the timeout property is set.

I think your problem may be caused by a blocking name lookup, and
there seems to be a fix in the standard library (see below)


Explanation:

From what I understand, the builtin DNS resolver just hands off to a
blocking system call -- which given the Ruby thread model means that
for the duration of that call no other threads will be scheduled (at
least, in 1.8).

The timeouts you specify won't apply to the system call, and I don't
think there's any way to specify ones that will given the standard
implementation, so it'll wait for the system default timeout (that 2m
delay sounds awfully familiar) before returning an error.


Possible solution:

I think the way to fix this is to replace the default resolver with an
alternative version that plays nicely with ruby threads - i.e.  by
wrapping a native async DNS library, or a implementing one in pure
ruby.

While I haven't tried this, I think you might be able to magically
solve this simply through the wonders of the standard library:

require 'resolv-replace'

Which seems to provide a pure-ruby resolver which should play nice
with threads.  I'm not sure if there are any consequences of doing
this though.

If that doesn't work, there seem to be several DNS related gems, maybe
someone else can provide more detail.


>And this error only happens on linux. Has anybody ever experienced
>anything like it?

Why it happens only on linux, I'm not really sure - if this is
something like ethernet with an unplugged network cable, I have this
vague idea that most linuxes don't actually take the interface down
when its unplugged, whereas maybe windows does - so on linux it tries
to send packets and wait for timeouts anyway, but maybe windows
disables/takes down the interface so it returns an immediate error?
Pure speculation on my part :)

Hope that helps (and please excuse the long-windedness :),
Stephen Lewis