www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How come unittesting std.socket takes 46 seconds?

reply Andrei Alexandrescu <andrei erdani.com> writes:
The second longest unittest is like 1.5 seconds.

I assume it goes outbound and initiates actual connections. A 
unittest should not connect to other hosts than localhost.
May 01
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu 
wrote:
 The second longest unittest is like 1.5 seconds.
~/work/extern/D/phobos/std » dmd -main -unittest -version=StdUnittest socket.d && time ./socket 1 modules passed unittests ./socket 0.05s user 0.15s system 92% cpu 0.211 total Between this and your AUTO_BOOTSTRAP woes, my most likely guess is that there is something wrong with your computer.
 I assume it goes outbound and initiates actual connections. A 
 unittest should not connect to other hosts than localhost.
Unfortunately that's not possible for things like testing DNS.
May 01
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/1/21 11:30 AM, Vladimir Panteleev wrote:
 On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu wrote:
 The second longest unittest is like 1.5 seconds.
~/work/extern/D/phobos/std » dmd -main -unittest -version=StdUnittest socket.d && time ./socket 1 modules passed unittests ./socket  0.05s user 0.15s system 92% cpu 0.211 total Between this and your AUTO_BOOTSTRAP woes, my most likely guess is that there is something wrong with your computer.
 I assume it goes outbound and initiates actual connections. A unittest 
 should not connect to other hosts than localhost.
Unfortunately that's not possible for things like testing DNS.
A special dedicated test mode should be for that. Routine unittests should not connect to the network.
May 01
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 1 May 2021 at 18:14:33 UTC, Andrei Alexandrescu 
wrote:
 A special dedicated test mode should be for that.
There already is something like that: `debug=std_socket` (and used via `softUnittest`).
 Routine unittests should not connect to the network.
Currently, an absence of Internet connection (without `debug=std_socket`) will not cause a failure. However, the absence of an Internet connection should still not result in a very long test duration. I don't know for sure what causes this in your case. My first guess would be that the computer thinks it's connected to the Internet whereas it actually has no connectivity (e.g. it's connected to a network which advertises a gateway but all packets sent to it are actually dropped). BTW, if this is still in WSL, I think that should be mentioned explicitly. I don't think we currently officially support that environment, and I'm not sure if we should expend much effort in doing so, considering that it's occasionally buggy and rapidly evolving. (I got bug reports that turned out to be due to filesystems in WSL behaving mysteriously and incorrectly, e.g. inability to rename a directory even with no processes accessing it.)
May 01
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 1 May 2021 at 15:01:31 UTC, Andrei Alexandrescu 
wrote:
 The second longest unittest is like 1.5 seconds.

 I assume it goes outbound and initiates actual connections.
It would be good to test that theory. Could you please attach a debugger and check the stack trace?
May 01