Re: TRY/CATCH is unnecessarily slow on OS X

["Lorenz Minder" <lminder@gmx.net>]

Hi,

Bill Allombert wrote:
> > I went and checked the POSIX spec this afternoon.  These are the main
> 
> Was it the standard or the draft ? It would not be te only place they differ.

That was IEEE Std 1003.1-2008, which is not a draft unless I'm very
confused.  The standard is available on the web at

	http://www.opengroup.org/onlinepubs/9699919799/

Check the pages on _setjmp() and sigsetjmp().

> > 3) sigsetjmp(,0) does not have to store the signal mask, but it can.
> >    sigsetjmp(,1) must store it.
> > 
> > 4) They say new software should not use _setjmp, but rather sigsetjmp.
> > 
> > I think that given that sigsetjmp(,0) may store the signal mask, the
> > advice 4) seems dodgy.
> 
> What is worse, this is misleading: if you let out performance (which is 
> not a POSIX concern), then the issue is that siglongjmp can restore the
> signal mask even if one do not want to.

Exactly.

> err_catch only purpose is to implement the current stacked exceptions 
> system which I find wholly inedequate and hope to replace.
> 
> Furthermore, TRY/CATCH is not documented currently,

While this is correct, no other error handling mechanism was documented
either.  Yet, any nontrivial program needs to handle errors.

>and mostly here 
> to implement the gp trap() function, which has its load of problem.

I see.  Are the problems in trap() related to CATCH/TRY itself?

> Adding a call-back 'cb_pari_err_restore' seems a better solution.

I think that would be a workable solution, too.

I looked at the current patch that you propose in the bug report (the
number of which I forget).  There's an issue with this solution that
makes it currently still unsatisfactory for me:  An error message is
emitted to stdout before the handler is called.

I think it really should not do that, it's a library after all.  What if
I want to use stdout to write results of my calculation to?  What if an
error is in fact some outcome that I can handle perfectly well? (Think
of ECM, for example.)

Do you think it would be possible to write the error message to a string
instead and pass that to cb_pari_err_restore, which then can print it or
otherwise use it?

That would be a big improvement.

> > I was actually going to propose a small change that makes it possible
> > for users to avoid anything setjmp()/longjmp() based, provided they can
> > come up with a viable alternative.  The idea is as follows.
> 
> I think it would be better to provide the user with the mean to implement
> their own TRY/CATCH alternative, and keep the setjmp()/longjmp() one
> for internal libpari use.

When it comes to libpari 2.3.x, is there any ill-effect if an
application uses TRY/CATCH?  If so, what else should it use?

Best,
--Lorenz
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser