G
Gordon Messmer
I've been working on a threaded daemon application to filter email. The
source for the program is here:
http://phantom.dragonsdawn.net/~gordon/courier-patches/courier-pythonfilter/
The daemon loads individual filters as modules and hands the names of the
message and control files to each module in turn for processing. One of
the modules (filters/dialback.py) checks the address of the sender,
connects to the MX servers for the senders domain, and validates that the
sender address is valid. In order to implement a timeout on the dialback,
each message is processed by two threads. The first thread creates an
SMTP object and then starts a second thread to do the lookup using that
SMTP object. If the lookup takes too long, the first thread closes the
SMTP object's socket and collects the failure from the second thread.
During testing, that all works fine. However, in real world use, the
program eventually deadlocks. When it does so, there are several dialback
threads in process, and the first of each pair seems to be reading from
the status pipe. I cannot connect a debugger to the second of the pair to
see what state it's in.
I'm running this application on python2-2.2.2-11.7.3 under Red Hat Linux
7.3.
Does anyone have any suggestions for where I can start looking for the
problem?
source for the program is here:
http://phantom.dragonsdawn.net/~gordon/courier-patches/courier-pythonfilter/
The daemon loads individual filters as modules and hands the names of the
message and control files to each module in turn for processing. One of
the modules (filters/dialback.py) checks the address of the sender,
connects to the MX servers for the senders domain, and validates that the
sender address is valid. In order to implement a timeout on the dialback,
each message is processed by two threads. The first thread creates an
SMTP object and then starts a second thread to do the lookup using that
SMTP object. If the lookup takes too long, the first thread closes the
SMTP object's socket and collects the failure from the second thread.
During testing, that all works fine. However, in real world use, the
program eventually deadlocks. When it does so, there are several dialback
threads in process, and the first of each pair seems to be reading from
the status pipe. I cannot connect a debugger to the second of the pair to
see what state it's in.
I'm running this application on python2-2.2.2-11.7.3 under Red Hat Linux
7.3.
Does anyone have any suggestions for where I can start looking for the
problem?