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 ba
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 c
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 stil
On Mar 3, 2:11 pm, Steve 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. That transition would be a
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 processed
> 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 ca
> > 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 release
13 matches
Mail list logo