On 07.02.2011 05:37, David Burton wrote:
On Sun, Feb 6, 2011 at 4:42 PM, Greg
Ewing <greg.ewing@xxxxxxxxxxxxxxxx>
wrote:
David Burton wrote:
(That's because, if you are an experienced programmer,
you have learned [probably the hard way] that you really
don't want to start anything complicated in response to a
click if you're deep in the bowels of the GUI code [which
has called your callback function], since the complicated
thing you start might want to /use/ that same GUI code,
and get button clicks and menu choices of its own, leading
to ever deeper recursion in the [hopefully reentrant!] GUI
code, and mind-bending complexity and bugs.)
there's a complicated thing to be done, it needs to be done
somehow
or other, and either way it's being done by a piece of code
being
called from the event loop, which will hold up the GUI until
it's
finished.
The difference is that with callbacks your application code
is not called from the event loop, it is called from
somewhere deep inside the GUI code.
With pygame events, your application code doesn't even see
the button-click or whatever until the GUI coded has finished
and exited, so the application author doesn't have to worry
about what can go wrong if he tries to do more user
interactions at that point.
With callbacks, if, when your application gets a button
clock or whatever, it then tries to do more user interactions,
it will be reentering the GUI code for a new user interaction
from deep within the GUI code itself, because the GUI code
hasn't yet returned from processing the previous user
interaction, because the callback from the application code
hasn't returned. When the second user interaction gets its
result, and makes its callback to the application,
both the application and the GUI are now reentrant! Two
different callbacks are now simultaneously active, and there's
no guarantee that the application code won't want to ask the
user another question, causing a third level of
reentrancy... and so forth and upward and onward, gee whiz!
Dave
Hi
" from deep within the GUI code itself" <-- how does that get
called? from the event loop?
and pushing the events on the pygame event loop could be dangerous
because it is possible that there are already other events on the
queue that will change the state of the application (or gui
elements) so that at the time when your event gets processed it
brakes (because the application isn't in the state anymore it was
when the event was posted). This is a very subtle bug and difficult
to catch. Not sure how to avoid that behavior (maybe posting the gui
internal events at the front of the event queue?). Therefore I think
callbacks are easier to work with. But I'm not entirely sure how to
handle reentrant calls, if there are any (is the recursion a problem
at all?). Normally only one user interaction (event) is processed at
the time. So i wonder:
"When the second user interaction gets its result, and makes its callback
to the application"
How?
Just my opinion.
~DR0ID
|