In the process of looking at my program's code again to write the lastentry , I think I may have solved the mystery ofhow my impossible exception gets generated.

My program does a lot of forking and thus cleanups of now-dead children.The code that it generally dies on is:

def _delip(pid, ip):  del ipmap[ip][pid]  if len(ipmap[ip]) == 0:    del ipmap[ip]

It takes a KeyError on the len

For a conceptually simple program, dd has a number of dark corners.One of them (at least for me) is how it deals with input and outputblock sizes, and how the various blocking arguments change thingsaround.

• ibs= sets the input block size, the size of the read() s that dd will make. Since you can get partial reads in varioussituations, this is really the maximum size that dd will everread at once.
• obs= sets the output block size and makes dd '

I have a heavily threaded Python program that dies every now and thenwith a mysterious exception (that as far as I can see just shouldn'thappen, which means that I don't completely understand my code).

My off and on attempts to debug this have pointed out a frustratingproblem in Python's (lack of) support for debugging threaded Pythonprograms: there's no such thing as a global exception, something thatwill freeze, backtrace, and terminate all threads when an erroroccurs.

It's pretty simple:

• change your syndication feed URL
• but don't remove or redirect the old feed, just stop updating it
• and don't put up an entry about it (visible in the old feed).

Readers who are not especially attentive may not notice for weeks, onlyvaguely wondering if you've taken a vacation or something. Especially ifthey read a fair amount of feeds and are behind in their reading.

As far as I've gathered, most feed readers are perfectly willing to