Lex,

#addDeferredUIMessage: is abused in various places to do a one-time
alarm (e.g., the equivalent to #addAlarm:after:). Why anyone would need
this is beyound me but check out PluggableTextMorph>>accept - I bet you
wouldn't expect to find #addDeferredUIMessage: here, eh?!. I think that
#addDeferredUIMessage: should simply raise an error if invoked from the
UI thread to explicitly prevent abuse such as in this example (and
that's not the only one but this particular place has bitten me big time
due to its side effects).

Back to your problem: Raise an exception! It's the right thing to do for
places where the response to some failed action depends on (possibly
application specific) context. Why should we poke ourselves with a stick
in the back and push forward (which is what that code is almost
literally doing) if we can just say "Sorry Dave, I can't do that" and
handle the problem in a place where we have enough information to react
intelligently?! Name lookup failure is an error and should be handled as
such. 

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Lex Spoon
> Sent: Sunday, November 03, 2002 12:21 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: DNS lookup problems in HTTP
> 
> 
> Lex Spoon <lex at cc.gatech.edu> wrote:
> > 
> > The method retry:asking:ifGiveUp:  has been modified to run from a
> > background thread -- but it seems to now *assume* it is 
> running from a
> > background thread!  Instead of "sema wait", it needs to do something
> > like "WorldState runWaitingOnSema: sema" or "WorldState 
> runUntil: [ sema
> > isSignaled]".  Are there methods of this kind in WorldState?!
> > 
> 
> Oh, an alternative would be for addDeferredUIMessage: to run its code
> immediately if you are, in fact, in the UI thread.  I'm not 
> sure how to
> detect this, though.
> 
> -Lex
>