| From | Sent On | Attachments |
|---|---|---|
| Marilyn Davis | Jan 13, 2005 2:04 am | |
| Danny Yoo | Jan 13, 2005 2:31 am | |
| Danny Yoo | Jan 13, 2005 2:41 am | |
| Marilyn Davis | Jan 13, 2005 3:17 am | |
| Danny Yoo | Jan 13, 2005 6:29 am | |
| Alan Gauld | Jan 13, 2005 10:20 am | |
| Marilyn Davis | Jan 15, 2005 11:19 pm | |
| Marilyn Davis | Jan 16, 2005 3:12 am | |
| Marilyn Davis | Jan 16, 2005 6:47 am | |
| Danny Yoo | Jan 16, 2005 7:40 am | |
| Marilyn Davis | Jan 17, 2005 5:02 am | |
| Danny Yoo | Jan 18, 2005 10:51 am | |
| Danny Yoo | Jan 18, 2005 7:24 pm | |
| Marilyn Davis | Jan 19, 2005 2:32 am | |
| Danny Yoo | Jan 19, 2005 8:12 am | |
| Kent Johnson | Jan 19, 2005 12:35 pm | |
| Marilyn Davis | Jan 19, 2005 8:57 pm | |
| Marilyn Davis | Jan 19, 2005 9:13 pm | |
| Danny Yoo | Jan 19, 2005 9:53 pm | |
| Marilyn Davis | Jan 19, 2005 10:28 pm | |
| Marilyn Davis | Jan 21, 2005 5:05 am |
| Subject: | [Tutor] sockets, files, threads | |
|---|---|---|
| From: | Danny Yoo (dy...@hkn.eecs.berkeley.edu) | |
| Date: | Jan 13, 2005 2:31:50 am | |
| List: | org.python.tutor | |
On Wed, 12 Jan 2005, Marilyn Davis wrote:
When stuff was read from the exim socket, it was stored in a tempfile, so that I could release the exim process, then I lseek to the front of the tempfile and have it handy. I see from all my debugging and logging that the file descriptor for this tempfile is 9.
Hi Marilyn,
Question: do you really need to use a tempfile? If your daemon is persistent in memory, can it just write to a StringIO object?
StringIO.StringIO elements act like files too, and may be easier to maintain than a tempfile.TemporaryFile. If you can show us how you're constructing and using the TemporaryFile, we can try to trace any problematic usage.
The program then opens a pipe to exim to send mail. I see that the popen2.popen3 call returns 9 for the stdin file descriptor for the pipe.
The tempfile (also file descriptor 9) is read for piping into exim and it errors with "Bad file descriptor".
Oh! This situation sounds like the 'tempfile' is being closed at some point, releasing the file descriptor back to the system. If that is what is happening, then that's why the pipe has the same descriptor id: the call to pipe() just reuses a free file descriptor.
I'd look for places where the tempfile might be close()d. I'd also look for places where your reference to tempfile is reassigned, since that would also signal a resource collection.
Worse yet, the first 5 messages of my test go through the entire process without a problem, and then # 6 hits this -- but only if # 1 message is really big.
Just double checking something: are you dealing with threads?
Best of wishes to you!





