Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#187 closed enhancement (wontfix)

Add a compiler flag to remove checks for GSL errors?

Reported by: Jari Häkkinen Owned by:
Priority: major Milestone:
Component: build Version: trunk
Keywords: Cc:

Description

Or should these checks be implemented as assert calls? There are some if statements used to check that memory allocation succeeded (such as gsl_vector_alloc), but these are really only needed if GSL error handler is disabled. However, a user of yat may disable GSL error handler without yat knowing it. A solution might be to create a utility function in yat to disable GSL error handling and making yat aware of this.

Change History (9)

comment:1 Changed 13 years ago by Jari Häkkinen

Status: newassigned

comment:2 Changed 13 years ago by Jari Häkkinen

Milestone: 0.3 (Public release)0.4
Owner: Jari Häkkinen deleted
Status: assignednew

comment:3 Changed 13 years ago by Peter

A question. How is GSL error handler enabled/disablded? When compiling GSL or at linkage time?

comment:4 Changed 12 years ago by Jari Häkkinen

Component: utilitybuild

comment:5 Changed 12 years ago by Jari Häkkinen

Milestone: yat 0.4yat 0.x+

comment:6 Changed 11 years ago by Peter

What is reason that we would like to turn off checks for gsl errors? speed?

IMHO, speed is only important in production code, and GSL recommends to turn off gsl_error_handler in production code. So there is no real reason to turn off these changes, because if we follow GSL recommendations GSL will not abort when an error occurs - and we want yat to detect the error and throw an exception. Needless to say, an exception is preferable to an abort as users can choose how to take care of the exception.

This leads to the formulation in source:trunk/README.developer

For production environments, yat and GSL users should turn off the default
GSL error treatment by calling gsl_set_error_handler_off(), but also
when yat's GSL error treatment is preferred.

which together with my conclusion above that exceptions are preferable over GSL's error treatment make me wonder if yat should call gsl_set_error_hander_off() by default. Either just calling the function prior calling any gsl function that might cause an error, or similarly create a singleton that does the same. The latter has the advantage that the singleton can also be used in a function such as yat_gsl_set_error_handler_on() which would tell the singleton not to turn off error handling.

comment:7 in reply to:  6 ; Changed 11 years ago by Jari Häkkinen

Replying to peter:

What is reason that we would like to turn off checks for gsl errors? speed?

IMHO, speed is only important in production code, and GSL recommends to turn off gsl_error_handler in production code.

With your reasoning there is no need to turn off yat checks of GSL error because another layer of checks in non-production code does not matter since speed is not an issue. Yes, but you assume that users of yat/GSL will turn off GSL error checking for production code. In general that will not be true and there will always be two layers of error checking. Since we actually discuss error checking in the developer README I think that we can always do GSL error checking.

which together with my conclusion above that exceptions are preferable over GSL's error treatment make me wonder if yat should call gsl_set_error_hander_off() by default.

Hm, I don't like the idea of turning of GSL error check by default. It must be the responsibility of the developer to make that call. yat could provide an interface for the call though.

Either just calling the function prior calling any gsl function that might cause an error, or similarly create a singleton that does the same. The latter has the advantage that the singleton can also be used in a function such as yat_gsl_set_error_handler_on() which would tell the singleton not to turn off error handling.

Hm, another call when I'd like to see only one error checking layer in production and developer code? The rationale is to use always use yat error handling? I am not sure, I suppose yat will take one step further away from thread safety (which isn't one of yat's goals to keep) which I don't like. GSL itself is thread safe.

Was the last paragraph just an idea of how to save this ticket from being closed as wontfix? I think we should simply close this ticket.

comment:8 in reply to:  7 ; Changed 11 years ago by Peter

Milestone: yat 0.x+
Resolution: wontfix
Status: newclosed

Replying to jari:

With your reasoning there is no need to turn off yat checks of GSL error because another layer of checks in non-production code does not matter since speed is not an issue. Yes, but you assume that users of yat/GSL will turn off GSL error checking for production code. In general that will not be true and there will always be two layers of error checking. Since we actually discuss error checking in the developer README I think that we can always do GSL error checking.

OK

Hm, I don't like the idea of turning of GSL error check by default. It must be the responsibility of the developer to make that call. yat could provide an interface for the call though.

unless that function would do something more than the gsl function, I see no reason to add to the yat interface.

Hm, another call when I'd like to see only one error checking layer in production and developer code? The rationale is to use always use yat error handling? I am not sure, I suppose yat will take one step further away from thread safety (which isn't one of yat's goals to keep) which I don't like.

I haven't fully understood how a singleton destroys the thread safety, but I buy your argument.

Was the last paragraph just an idea of how to save this ticket from being closed as wontfix? I think we should simply close this ticket.

Sure.

comment:9 in reply to:  8 Changed 11 years ago by Jari Häkkinen

Replying to peter:

Hm, another call when I'd like to see only one error checking layer in production and developer code? The rationale is to use always use yat error handling? I am not sure, I suppose yat will take one step further away from thread safety (which isn't one of yat's goals to keep) which I don't like.

I haven't fully understood how a singleton destroys the thread safety, but I buy your argument.

Well, neither do I, it is just a gut feeling. Imagine some part of the program wanting to turn off checking while some other part wants to turn it on ...

Note: See TracTickets for help on using tickets.