On Monday 02 March 2009 18:38:06 Matthew Miles Clark wrote:
Thanks for taking a look at this. All in all I'm very impressed by
Kamaelia and look forward to working with it.
Glad to hear that. :-)
Incidentally, I've looked at this:
data_files=[ ('share/kamaelia', ['App/kamaelia_logo.png'])
Ah, I forgot the original context you were working in!
I did too :) I didn't communicate it clearly, I think. I was trying to
accomplish too much too quickly.
This is exactly what I hoped for, a solution that would not force me to
disconnect and reconnect.
Let me give this a go and get
Michael,
I was reviewing the TCPClient.py code. In the runClient method you
have:
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM);
yield 0.3
self.sock = sock # We need this for shutdown later
try:
sock.setblocking(0); yield 0.6
try:
On Tuesday 03 March 2009 19:26:57 Steve wrote:
Michael,
I was reviewing the TCPClient.py code.
Many thanks for this. As a preface to what follows, I've put a different
implementation into TCPClient - in line with my comments yesterday. The
reason is to allow TCPClient to continue to not
Michael,
Thank you for your detailed explanation. I did see what you checked
in before I started looking at the timeout capabilities. I have to
think there is a better way still. I've been doing some testing and
here is what I have found.
On windows, with the timeout = 0, all you get are the
Ok, I think I'm starting to get what's going on here on my windows
box:
1) We try to connect non-blocking
2) There is no immediate error so an EWOULDBLOCK is thrown
3) The connection attempt magically continues in the background
4) We loop around and try to connect again
5) The process may be
On Mar 3, 2:11 pm, Steve unetright.thebas...@xoxy.net wrote:
What should happen in my opinion is that at some point we should go
from getting WSAEINVALID back to a single EWOULDBLOCK when the first
connection is refused and then a brand new connection is started. But
we never do see that.
On Tuesday 03 March 2009 22:11:11 Steve wrote:
The real problem is we need a way to set a timeout on the connection
attempt in the background without making it blocking.
Yes, this is what I've done :-)
OK, not without sucking CPU, but I did say The cost at present is higher
CPU usage than
Hi,
self.pause() in generator components has the follow effects:
* It schedules a request with the schedule to pause the generator. cf:
self.scheduler.pauseThread(self)
This actually adds a pauseRequest for the microprocess on a threadsafe
queue. That queue is periodically
The upshot is that pause() tells the scheduler please don't call me again
unless there's a new message in an inbox OR a message is taken from an
outbox.
... OR if a child component terminates :-)
For threaded components it means the same thing. However, since a threaded
component can
class TCPClient(Axon.Component.component):
def __init__(self,host,port,delay=0,connect_timeout=60):
self.connect_timeout = connect_timeout
...
connect_start = time.time()
while not self.safeConnect(sock,(self.host, self.port)):
Thinko, I meant:
waitTill = time.time() + self.connect_timeout
while not self.safeConnect(sock,(self.host,
self.port)):
if self.shutdown():
return
if time.time() = waitTill:
Michael,
I was looking through the UDP_ng code. Maybe I missed something, but
I can't find any tear down code. SimplePeer, TargettedPeer,
PostboxPeer; all three exit their while loop in response to a
shutdownMicroprocess, but they don't clean anything up.
Since my problem is they don't
13 matches
Mail list logo
