Re: TRY/CATCH is unnecessarily slow on OS X

[Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>]

On Mon, Aug 24, 2009 at 01:03:13AM -0700, Lorenz Minder wrote:
> Hi,
> 
> I see two potential problems with this patch, though.  The first one is
> that it incompatibly changes the err_catch() function (and it does so in
> a way that is not necessarily compile-time detected).  I don't know what
> the compatibility requirements of PARI are;  I can't find any
> documentation of err_catch(), so I'm not sure if its users are supposed
> to be on their own if this interface changes, or if it is maybe
> necessary to introduce a new err_catch2() function, and leave the old
> function as is.  (It would certainly be possible to keep track of
> whether a stored jump buffer is a sigjmp_buf or a plain jmp_buf.)

err_catch is only supposed to be used through the TRY/CATCH macros so this is
not an issue. What is more problematic is changing the type of DATA->env:
User code might do setjmp(GP_DATA->env) and be broken by the change.
So maybe we could use _setjmp/_getjmp instead of sigsetjmp/siglongjmp.
(It is also slightly confusing to use the sig* varianltin order *not* to save
signals).

> The other possible problem is that error handling is supposed to be
> reworked in any case if I understand correctly.  Unless I'm misreading
> the plan, this would likely need a new API anyways, so it might be a
> better plan just to change the API just once.  If that is the case, what
> would be the best thing for me to do to ensure that the new API does not
> have the same performance problems on BSD-style platforms as the current
> one does?

We will change error handling, but this will still use *setjmp/*longjmp
anyway.

A note on the patch: I would prefer if pari_setjmp/pari_longjmp were
real functions and not macros.

Cheers,
Bill.