On Tue, Feb 26, 2002 at 04:52:29PM +0100, Pascal Levy wrote:
>>> [...] if the callback you supply
>>> throws an exception, the temporary stack allocated in SysQSort is never
>>> freed, since control returns directly to your code. A very simple
>>> improvement would be that SysQSort catch the exception, clean up, and
>>> rethrow it.
[...]
> I was talking of the ErrTry/ErrCatch/ErrEndCatch block, and the ErrThrow
> function. It seems reasonable to think that this is the lowest common
> denominator, since it is the mechanism provided by the OS.
Oh, *those*. I didn't realise anybody actually used them :-).
You're absolutely right: they're supplied by the operating system, so
if you think Palm OS is one cohesive whole, you would expect operating
system functions to survive Palm OS exceptions being thrown through
them. Most API functions know what they're calling (namely other OS
functions), so this wouldn't be an issue for them. But API functions
which call application-supplied callbacks ought to assume that the
callback might ErrThrow and ought to take precautions accordingly,
cleaning up and rethrowing.
Hmmm... Palm OS... cohesive whole... I think I just saw where this
argument breaks down. :-)
Incidentally a comment in ErrorBase.h says
Destructors for stack-based objects which go out of scope as a
result of the ErrThrow() are called.
which appears to suggest that SysQSort() ought to be able to arrange for
its memory to get freed even without its own ErrCatch. However ErrorBase.h
doesn't say what on earth such a "destructor" might be or how you might
specify one, nor does the implementation (a simple set-jump/long-jump
mechanism) of this stuff do anything of the sort. Clearly the comment
about destructors is a load of misleading rubbish. (Perhaps they meant
"*C++* destructors ... are *not* called", which would make sense.)
>> Throwing exceptions back through an OS function is not a very good idea
>> and in fact is probably undefined (?).
>
> On simple functions like SysQSort, this works perfectly, modulo the memory
> leak.
Well, "perfectly" modulo having their cleanup entirely bypassed! This
suggests an interesting attack on DmQuickSort(), but sadly I see Mike
Chen closed the hole a while back. :-)
> There is no way to stop the sorting process from within the callback
> function. And exception entry code is slow. The callback beeing called about
> n*log(n) times, I'd rather catch exceptions globally than locally.
Okay, so you really do want to abort the sort immediately. Fair enough,
but it's not something that's supported by SysQSort(), which isn't
ErrException-safe. You do have the option of writing your own sort
routine, at which point you have the opportunity to abort via any
mechanism you like -- and you're sure to find a more efficient one than
ErrorMgr exceptions.
Another option suggests itself: Are you sure that non-aborted sorting
really is a bottleneck in your application? What is this weird dataset
in which comparisons can fail fatally anyway? The only thing I can
think of is that you have a bunch of references of some kind in memory,
and doing the comparison means dereferencing, which means looking up the
pointed-to records in some expensive way that might fail. And so you'd
like to avoid the rest of the sorting and lookups if the sort has
already failed.
If these wild guesses are correct, I wonder if all you really need to
avoid is wasted *lookups*; continuing to sort might not be a problem.
In this case, what about a comparison function like
Int16 cmp (void *a, void *b, Int32 other) {
if (indicates_weve_already_failed (other))
return (char *)b - (char *)a;
else
return do_the_real_lookup_and_cmp (a, b, other);
}
(For the record: Ben Combee wrote:
> CodeWarrior uses zero-overhead exceptions, which should execute no
> additional code unless you actually throw an exception
Ditto GCC. Essentially zero extra code gets executed unless/until you
throw something.)
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
