> On 24 Feb 2017, at 18:14, Ben Coman <[email protected]> wrote: > > > > On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe <[email protected]> wrote: > > > On 20 Feb 2017, at 10:30, Pavel Krivanek <[email protected]> wrote: > > > > > > > > 2017-02-20 10:27 GMT+01:00 Guillermo Polito <[email protected]>: > > As far as I remember, the main problem was not bandwidth but a blocking and > > non-responsive UI. > > Imagine I'm in the university, or in a company with a proxy. And I forget > > to set the proxy. Then, while spotter tries to fetch catalog entries, it > > would block the image and throw a timeout error some minutes after. > > > > So, maybe for the future and besides Ben's C option (which I like) I have a > > > > D) Load catalog entries in background in a non-blocking way > > - and while catalog entries are not yet available, they should not be > > shown > > > > AFIK the main problem was that there was not possilbe to do it non-blocking > > way. > > Yes that is true. (It is actually DNS resolving that is blocked in some freak > case). > > In sqUnixSocket.c I read... > * Notes: > * Sockets are completely asynchronous, but the resolver is still > synchronous. > > So does this mean that if for any reason the resolver primitive takes a long > time to respond, > the whole VM is blocked? Thus forking the Catalog loading in another thread > would have no benefit?
Yes and yes. > Would having the resolver coded purely in-Image behave better? Yes (probably). > So a slow name resolution would not hold up the whole image if it happened in > a forked thread. Yes. > I found such an implementation in OpenCobalt and after some minor cleanup > basic operations work fine. > > http://smalltalkhub.com/#!/~BenComan/DNS/ Well, I did one myself too (I have not looked at the one above, I will), but my conclusion was that it is not that difficult to get basic lookup working, but edge cases (like concurrent requests with intermixed answers) are not so easy. There is also a chicken/egg problem: what DNS resolver (host) will you contact ? How to find out the one configured by your OS ? My idea was to use the Google ones (8.8.8.8), but there is also a more open one (80.80.80.80) and probably others. We are often accused of reinventing the wheel and carrying the burden of maintaining all that infrastructure. Doing our own DNS client would add to that. But I like the general idea, the question is one about development risk. > cheers -ben > > But the thing is, the problematic situation only occurs for a very small > percentage of people, like less than 1%, probably even much less. (Remember, > nobody can produce a repeatable case for it). > > So the question is, is that enough reason to act as if we are still in the > 90's when internet was a luxury and cut features that depend on it ? If you > have no network today, you're in big trouble anyway. (Again, if you turn off > your network, no blocking will happen at all, try it). > > So what is more important ? The general functionality of the 99.xxx % or the > unreproducible freak case ?
