finalizing - maybe I'm not describing my usage correctly. I've used
reactor.callLater(0,blah) as a means of starting a unit of work the
by-product of which the caller didn't need.
this is really a case of laying tracks for 2 years not fully comprehending
the train coming down the tracks behind me
It might be, but I can't think of a reason off hand why it ever _should_
be. I can kind of see how it might work, but if your "async" process ever
takes longer than your callLater delay it will break, and probably quite
horribly.
On Wed, Jul 9, 2014 at 12:11 PM, Kevin Mcintyre wrote:
> Another
Another "Oh right" twisted moment. callInThread instead of callLater?
This is a case where I've been laying tracks for 2 years without totally
understanding the train that was eventually coming down the tracks. I
guess I implicitly understood by wanting to move to a separate reactor as a
separat
On 5 Jul, 08:35 pm, kebi...@gmail.com wrote:
calling reactor.callLater within qt4reactor in an attempt to async non
webkit work but not seeing expected behavior. Webkit locks while the
callLater function executes.
`callLater` does not make a blocking function into a non-blocking one.
It just
calling reactor.callLater within qt4reactor in an attempt to async non
webkit work but not seeing expected behavior. Webkit locks while the
callLater function executes.
Any insight appreciated.
Should I move real work into separate reactor and "broker" calls into
qt4reactor/webkit. I have xmlrp
