Look at this round-robin DNS example and ask yourself what you would expect to happen:
test.example.com. 60 IN A 127.0.0.1
test.example.com. 300 IN A 127.0.0.2
I expected that one record would be cached for 60 seconds and the other would be cached for 300 seconds. The reality is that both records will be returned with the same TTL, namely the lowest one. I haven’t been able to find this documented anywhere, but I have confirmed this behavior on both Microsoft and BIND DNS servers, so I’m assuming it’s some sort of a standard. I’ve also only found one mention of this (with a reply from a Microsoft MVP who obviously doesn’t know what he’s talking about), so I wonder how many other people are aware of this.
I keep getting bit by this stupid problem, so I’ve decided to finally document the fix:
c:\> net use x: \\192.168.1.1\share\
System error 53 has occurred.
The network path was not found.
The problem is the trailing slash at the end of the UNC path.
c:\> net use x: \\192.168.1.1\share
The command completed successfully.
I came across some interesting articles on the subject of killing child threads from a main process. I had only done this before in C# .NET, so I assumed this was a regular feature of threads, but then I discovered that Python has no built-in way of doing this. Java used to, but the methods are deprecated now. Considering all this, I find it interesting that Microsoft allows you to do it anyway (not that Microsoft is exactly known for doing things The Right Way™)!
So the recommended way to kill a child thread is through the use of a boolean variable within the child thread instance itself. The thread should poll this variable regularly within its “run” method to determine whether or not the thread should stop itself.
That’s simple enough. Unfortunately, I find this to be an inadequate solution when dealing with blocking I/O calls, since you still have to wait for the function to return. I wonder how people get around things like this when writing GUI apps, which generally need to be responsive at all times…
Update: I have now discovered wx.lib.delayedresult. However, I have also discovered the hard way that widgets should never be updated by worker threads. Doing so results in strange errors and segfaults in GTK.