|Bill Allombert on Tue, 25 Aug 2009 14:44:54 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: TRY/CATCH is unnecessarily slow on OS X|
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.