[Wxsqueak] Putting halts in event handlers

[dan]

Hi Rob

If I put a halt in the method WxDemoTreeCtrl>>#onCompareItems:item2:,
doing something that triggers that handler causes the VM to crash. Is
that something you expect at this stage?

Cheers

Daniel

[Rob Gayvert]

Hi Daniel,

It turns out that this is the worst-case scenario for callbacks. In this
demo, this method comes from a callback that is triggered by an event
callback, so there are two return points on the C stack. When the halt
is encountered, WxEvtHandler class>>checkCallbackException is run, but
it restores the wrong point on the C stack, crashing the VM.

There are a couple of difficulties here. The exception check could be
improved to avoid the crash (it should check for the generic case
first), but then you wind up with a big pile of debugger windows, since
after restoring the C stack, the calling routine in the wx library
continues doing its comparisons.

I'm currently working on unifying the two different kinds of callbacks
in order to avoid this kind of problem. Even then, though, if you put a
halt inside a Squeak callback method, you're going to get some odd
behavior, because the callback must be completed back to the wx library.
Your best bet in this case is to use some old-fashioned logging (e.g.,
Wx logMessage:). Not very Smalltalk-like, but it's safe.

.. Rob

Post by dan
Hi Rob
If I put a halt in the method WxDemoTreeCtrl>>#onCompareItems:item2:,
doing something that triggers that handler causes the VM to crash. Is
that something you expect at this stage?
Cheers
Daniel

[dan]

Hi Rob

Post by Rob Gayvert
Hi Daniel,
It turns out that this is the worst-case scenario for callbacks. In this
demo, this method comes from a callback that is triggered by an event
callback, so there are two return points on the C stack. When the halt
is encountered, WxEvtHandler class>>checkCallbackException is run, but
it restores the wrong point on the C stack, crashing the VM.
There are a couple of difficulties here. The exception check could be
improved to avoid the crash (it should check for the generic case
first), but then you wind up with a big pile of debugger windows, since
after restoring the C stack, the calling routine in the wx library
continues doing its comparisons.

That old chestnut...
Sounds pretty much like what happens when you put a halt in a VSE
callback: you also get a 'big pile of debugger windows' in certain
situations.

Post by Rob Gayvert
I'm currently working on unifying the two different kinds of callbacks
in order to avoid this kind of problem. Even then, though, if you put a
halt inside a Squeak callback method, you're going to get some odd
behavior, because the callback must be completed back to the wx library.
Your best bet in this case is to use some old-fashioned logging (e.g.,
Wx logMessage:). Not very Smalltalk-like, but it's safe.

If you get an exception in the callback, it seems like you catch it and
ignore it, right?

We have been discussing callbacks in the general squeak list. It looks
like you have done some interesting stuff regarding putting callback
support into the VM. Is that right?

Cheers

Daniel

[Rob Gayvert]

Post by dan
If you get an exception in the callback, it seems like you catch it and
ignore it, right?

It's not entirely ignored -- the callback is "completed" by restoring
the C stack, and then it opens a debugger on the Squeak callback
process. If it's a one-shot deal, this can be useful. But in a case like
this tree item comparison, it can be a mess. The bottom line is that you
have to be very careful with what goes on in a callback.

Post by dan
We have been discussing callbacks in the general squeak list. It looks
like you have done some interesting stuff regarding putting callback
support into the VM. Is that right?

I can't claim to have invented anything new (the ideas are all from
Andreas), but the end result is interesting. In the 0.4 release, the
callbacks were handled entirely within WxPlugin, without any core VM
support. The downside of this was that the callback processes were hard
to control, so any API call that might result in a nested callback had
to be guarded with a special semaphore. In 0.5, I'm using Andreas' new
VM modifications, which makes the calls much cleaner, and should be more
stable as well.

.. Rob

[Daniel Poon]

Post by Rob Gayvert
If it's a one-shot deal, this can be useful. But in a case like
this tree item comparison, it can be a mess. The bottom line is that you
have to be very careful with what goes on in a callback.

When I was trying to understand how wxSqueak works, I put a halt in a callback
so that I could learn what the call stack looked like. Unfortunately, I got more
than I expected!