On Feb 12, 2010, at 9:51 PM, K. Richard Pixley wrote:
> I'm working with parallelized build servers. We often have raided
> disks, solid state disks, servers with huge amounts of disk cache
> specifically so that an entire build happens in memory, etc. File io is
> our bottleneck.
Yeah, thi
Glyph Lefkowitz wrote:
> If you only have one disk, you can only really get a benefit from two, maybe
> three file I/O slave processes, and that's a fairly small amount of resources
> to manage. Granted, it's tricky to really identify how many "disks" you've
> got in a system, and the performan
On Feb 12, 2010, at 3:11 PM, exar...@twistedmatrix.com wrote:
> On 07:35 pm, r...@noir.com wrote:
>>
>> Er... on second thought... isn't there still a utility in asynchronous
>> file io which yields to the reactor?
>>
>> It may be always readable/writable, but if I simply read/write, I'll
>> b
On 07:35 pm, r...@noir.com wrote:
>exar...@twistedmatrix.com wrote:
>>It isn't `doRead`'s job to close the file descriptor. At most, it's
>>`doRead`'s job to signal that the descriptor is no longer worth
>>keeping
>>open by returning something like an instance of ConnectionDone or
>>ConnectionLos
exar...@twistedmatrix.com wrote:
> Also, you won't accomplish much by adding a file descriptor for a normal
> file to the reactor. Select, poll, etc, will always indicate that such
> descriptors are both readable and writeable.
Er... on second thought... isn't there still a utility in asynchrono
exar...@twistedmatrix.com wrote:
> It isn't `doRead`'s job to close the file descriptor. At most, it's
> `doRead`'s job to signal that the descriptor is no longer worth keeping
> open by returning something like an instance of ConnectionDone or
> ConnectionLost. Then the reactor will call conn
On 07:24 pm, r...@noir.com wrote:
>I don't think so. I believe the reactor is actually added during the
>import. (I learned this as I discovered that reactors can't be
>restarted, which means you have to manually create a new one as a
>fixture for simple unittest work.)
>
>I looked through the
Doh. You're right about the double registration. Thanks. But that
doesn't change my problem.
The reactor still complains about the busted descriptor after removing
the reader and reseting my descriptor to -1.
--rich
Mark Bailey wrote:
Hi Rich:
Try removing the "reactor.addReader(self)"
Hi Rich:
Try removing the "reactor.addReader(self)" call from "__init__" and see what
happens. That call is made when "r" is created in
r = inputFile('/etc/group')
and immediately after that you are calling
reactor.addReader(r)
So, you are calling reactor.addReader() twice on the same in
I don't think so. I believe the reactor is actually added during the
import. (I learned this as I discovered that reactors can't be
restarted, which means you have to manually create a new one as a
fixture for simple unittest work.)
I looked through the code and there's a call in the reactor
Hi:
Aren't you adding two readers? One is added in the __init__ method of
inputFile, the other in the test code.
I'm also a newbie so maybe I'm equally confused...
On Tue, Feb 9, 2010 at 8:47 PM, K. Richard Pixley wrote:
> I'm confused be the response I get to the attached program.
>
> In a
I'm confused be the response I get to the attached program.
In a nutshell, I'm building a reader, attaching it with addReader, later
removing it with removeReader. And I'm getting this:
time python test_reactor.py
Traceback (most recent call last):
Failure: twisted.internet.error.Con
12 matches
Mail list logo
