Thank you very much for your explanation! Now I've understood what's the
problem in iterate().

On these lines I've prepared a this little test case (in attach):

Test 1

$ python runner.py
click on the button
minimize/unminimize window to force a widget redraw, the window should be
blank.
you can click another time on the button, the event is catched but no
"button animation" is performed

Test2

$ python runner.py
open another console
$ python runner_other_process.py
click on the button of runner_other_process, this connects itself to the
server in the first process
each window should redraw correctly

2010/5/24 Glyph Lefkowitz <[email protected]>

>
> On May 23, 2010, at 6:36 PM, Gabriele Lanaro wrote:
>
> > In which sense it's invalid? I don't know how the gtk reactor works, I
> just guessed that the event loop never reaches the gui events. My idea was
> to force the processing of these events before spawning another deferred,
> it's just a workaround, the real problem is  the fact that the server and
> the client resides in  the same loop (for testing).
>
> It's invalid to run reactor.iterate() inside the reactor mainloop.  You
> can't force event-processing order in Twisted; if you want an event to not
> get processed, you need to delay its event source from getting invoked
> (producer.pauseProducing(), transport.stopReading(),
> transport.stopWriting(), Deferred.pause() are all ways to do this).
>
> It's invalid to use reactor.iterate() in this way because the reactor may
> invoke you reentrantly and there's no sane way to handle that.
>
> For example, your code is running because select() said your file
> descriptor was ready for reading, which then invoked dataReceived, which
> then invoked your method with buffered data, which then called iterate(),
> which then called dataReceived, which then called your method with buffered
> data, which then called iterate(), which then ...
> (and so on, forever, unless your application code conflicts with itself and
> running and starts blowing up and throwing incomprehensible tracebacks
> everywhere because of "impossible" recursion.
>
> > Which can be the reason of the mainloop "block"?
>
> Lots of reasons.  The example you gave wasn't syntactically valid Python,
> so it's hard to say.  Consider sending along an <http://sscce.org/> and
> maybe we can tell you more :).
>
>
> _______________________________________________
> Twisted-Python mailing list
> [email protected]
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>

Attachment: twistsample.tar.gz
Description: GNU Zip compressed data

_______________________________________________
Twisted-Python mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Reply via email to