Danny! I couldn't resist trying threading again, now that the
mysterious single-threading behavior is gone.
I didn't put any locks anywhere.
And it runs like a champ.
Like a super champ.
Either I had to put back threading or I had to make a family of
socket-readers, or lose some functionality
On Wed, 19 Jan 2005, Danny Yoo wrote:
> On Wed, 19 Jan 2005, Marilyn Davis wrote:
>
> > class Exim:
> > def __init__(self):
> > self.fdin = None
> > self.err_flush = []
> > self.stdout, self.stdin, self.stderr = popen2.popen3('%s -t' %
> > MAILER)
> > se
On Wed, 19 Jan 2005, Marilyn Davis wrote:
> class Exim:
> def __init__(self):
> self.fdin = None
> self.err_flush = []
> self.stdout, self.stdin, self.stderr = popen2.popen3('%s -t' %
> MAILER)
> self.fdin = self.stdin.fileno()
> self.fdout = s
Thank you Kent.
On Wed, 19 Jan 2005, Kent Johnson wrote:
> Marilyn Davis wrote:
> >>few lines up, right where 'client_socket' is initialized. Like this:
> >>
> >>###
> >>try:
> >>client_socket, client_addr = self.server_socket.accept()
> >>Spawn(client
>
> > What about when I do an explicit call to a close inside a __del__. Is
> > that a bad idea?
>
> I usually prefer to add a close() method to my objects that releases
> resources, rather than __del__(), because it's more visible.
>
OK Danny! I found it! When I was almost asleep last night
Marilyn Davis wrote:
few lines up, right where 'client_socket' is initialized. Like this:
###
try:
client_socket, client_addr = self.server_socket.accept()
Spawn(client_socket).start()
except socket.error, msg:
time.sleep(.5)
On Tue, 18 Jan 2005, Marilyn Davis wrote:
> while 1:
> if log.level & log.calls:
> log.it("fd%d:py_daemon.py: Waiting ...", self.descriptor)
> try:
> client_socket, client_addr = self.server_socket.accept()
> except (EOF
Thank you so much Danny. I know how hard it is to look at and comment
on other people's code. You know I teach C and Python and I have to
say, though, that reading students' Python is 100 times easier than
reading their C.
And, I hope you're feeling better. I hate to think of you struggling
thr
On Tue, 18 Jan 2005, Danny Yoo wrote:
> In fact, as far as I can tell, none of the Spawn() threads are
> communicating with each other. As long as your threads are working
> independently of each other --- and as long as they are not writing to
> global variables --- you do not need locks.
>
>
Hi Marilyn,
[Long program comments ahead. Please forgive me if some of the comments
are overbearing; I'm trying to get over a cold, and I'm very grumpy.
*grin*]
Some comments on the code follow. I'll be focusing on:
> http://www.maildance.com/python/doorman/py_daemon.py
One of the import
On Sat, 15 Jan 2005, Danny Yoo wrote:
>
>
> > I have only wrapped my lock around file-descriptor creations. Should I
> > wrap it around closings too? Or the whole open -> close transaction?
> > It sounds like error-prone work to do the latter. What am I missing?
>
> Hi Marilyn,
>
> Can you
> I have only wrapped my lock around file-descriptor creations. Should I
> wrap it around closings too? Or the whole open -> close transaction?
> It sounds like error-prone work to do the latter. What am I missing?
Hi Marilyn,
Can you send a link to the source code to the Tutor list? I'm ge
p.p.s.
I have only wrapped my lock around file-descriptor creations. Should
I wrap it around closings too? Or the whole open -> close
transaction? It sounds like error-prone work to do the latter. What
am I missing?
What should I be reading to get a better clue?
I'll do some googling.
Thank
Dearest Tutors,
Bah! It's not over yet. I don't know why, but again my file
descriptors are being trampled upon now and then.
This time I can see in my log that I'm not trampling on them myself,
like I used to do, unless I'm making calls to the system that I'm not
aware of.
And, first I get th
Whew! What a trip this bug has been!
Danny was exactly right here:
> is exactly the sort of thing I'd expect if two threads were
> contending for the same resource, so let's see if the bug has to do
> with this.
This bug drove me nuts. (it's a short drive)
So I started wrapping my file open
> Where did my 'ooo' go?
>
> #! /usr/bin/env python
> import os
>
> fobj = open('/tmp/xxx','w')
> fobj.write('ooo\n')
fobj.flush()
File objects use buffered IO and by changing from using file
objects to file descriptors half way through the buffer
could be in any state. You need to flush() to
On Wed, 12 Jan 2005, Marilyn Davis wrote:
> I was looking at my use of file objects and file descriptors and I wrote
> this sample program and was very surprised by the result -- which makes
> me think there's something here that I don't understand. Where did my
> 'ooo' go?
>
> #! /usr/bin/env p
On Wed, 12 Jan 2005, Danny Yoo wrote:
Thank you so much for thinking about this Danny.
> > 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 debu
> Just double checking something: are you dealing with threads?
Hi Marilyn,
Argh, that was a dumb question. Pretend I didn't ask it that way.
*grin*
I meant to ask:
How do you deal with threads? Is the temporary file a global resource
that the threads all touch? If so, have you done any sy
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 th
Hello Tutors,
I've been banging my head against this bug for 4 days.
I can't think of how to ask for help except to give a birds eye view
of the situation.
I have a python daemon that is listening on a UNIX socket for
communication with exim, my Mail Transfer Agent.
Each mail message has its ow
21 matches
Mail list logo
