This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Proposal for non-malloc versions of block, vector, matrix functions


William Brower wrote:

> In our "mission critical" software,
> we try not to explicitly malloc anything
> except during the initialization phase.
> In this phase, static memory is allocated and re-used
> during the most critical run-time phases.
>
> For example, in some file: file1.c:
>
> static int *pi2_list = NULL;
>
>     int file1_init(void) {
>
>       pi2_list = malloc(500*sizeof(int));
>
>       return 0;
>       }
>
>     int file1_thread_workhorse(void) {
>
>       ...here, we use and reuse the pi2_list array...
>
>       return 0;
>       }
>
> We'd like to support the same concept with gsl data types.
> Specifically, we've written "noalloc_from_mem" versions
> of all the block, matrix and vector "alloc" functions.

I don't understand why you need this function.
Your file1_init function could simply create a gsl_block
instead of an array of int:

    static gsl_block* pi2_list = NULL;

    int file1_init(void) {
      pi2_list = gsl_block_alloc(500);
      return 0;
      }

    int file1_thread_workhorse(void) {
      ...here, we use and reuse the pi2_list block...
      return 0;
      }

> These new functions get passed a pointer which can be used
> in place of pointer that would be returned by the "malloc".
> Of course, there are many ways to screw this up; that is,
> it can be considered more dangerous than a malloc.
>
> An example where we find it useful though is in some thread
> that is called 10 times a second which would need to call
> gsl_matrix_alloc. Instead, we would call it once in an initialization
> function, and then use the matrix_noalloc_from_mem function
> in the thread workhorse and pass to it the pointer from the malloc.
>
> We use GSL version 0.6 (or principle reason
> for not upgrading to version 0.7 and beyond
> is the maintenance of these new functions).
> Our question is: would you entertain the idea
> of adding functions such as these to the GSL repository?

I'm not sure what you mean by "mission critical".
If you need highly reliable software,
you should be using Ada and not C
and you certainly shouldn't be using the GSL.
If you are writing real time software,
you should remember that the GSL is NOT a real time library.
If you are writing high performance software,
the GSL is probably NOT the best choice.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]