Dan Mosedale wrote: > [CCing [EMAIL PROTECTED] with permission] > > Darin Fisher wrote: > >> Doug Turner wrote: >> >>> Darin Fisher wrote: >>> >>>> Yes, I agree (sort of). I don't think other threads will be >>>> calling res_init, but other threads might call gethostbyname while >>>> _the_ DNS thread is calling res_init, which might be an issue (see >>>> for example nsDNSService::Resolve). Resolve is called by a socket >>>> transport when opening a blocking input or output stream (IMAP >>>> opens blocking output streams, I think... or does it now use >>>> AsyncWrite... hmm). PAC also calls Resolve, which is triggered via >>>> preferences. >>> >>> >>> Ick! >>> >>> Why can't we queue this dns request and block the caller of Resolve()? >> >> >> we certainly could do that, and maybe we should?! >> >> what about the LDAP SDK... does it call gethostbyname? > > > The C SDK does call gethostbyname. However, since that can > potentially block, the XPCOM SDK (and thus the client) instead goes > out of its way to call nsDNSService::Lookup() and then wait for a > callback. Then the pre-resolved address is handed into the C SDK, and > doing gethostbyname on an IP address won't block. > > It would be helpful to have a bit more context here.... > > Thanks, > Dan
Context: on 'nix, the dns resolver is not reinitialized when there are dhcp changes or other related os networking events. The result is that dns lookups start failing when you change your networking settings (think about going from home to work with a laptop - quite painful - you must *exit* out of mozilla and restart it to get dns resolution working again!). Now, on *some* systems res_init() is available. And its use is quite restrictive in terms of where and when it can be called. We have been kicking around different ideas and one of them was to restrict who calls gethostbyname. I do not think that this is a workable solution since we can't tell every embedder that they can't call gethostbyname directly (or can we?!). The two solutions that we have on the plate now is (a) call res_init IFF it is has a known threadsafe implementation. This would mean, on linux for example, only certain glibc's would work. Plan (b) would take advanage of a known feature/implementation of newer glibc's. We would kill the current dns thread and create a new one. It appears that a new thread does get a new dns resolver. Right now, I am reading over the glibc code for various version to see if they are threadsafe. Some docs that I have read suggest that this call is not. What we are worried about is thread (a) to be calling gethostbyname_r and thread b to call res_init(). more soon... Doug Turner [EMAIL PROTECTED]
