Re: [ECOS] handle and structures

[Bart Veer <bartv at redhat dot com>]

>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

    Fabrice> Most of the objects created cyg_*_create function are
    Fabrice> refered to by an handle (type cyg_handle_t) but in the
    Fabrice> meanwhile they need some memory to be allocated, which
    Fabrice> address is usually passed as the last parameter of the
    Fabrice> *_create function (which type is cyg_thread,
    Fabrice> cyg_interrupt, etc...)

    Fabrice> So before to call the _create function I usually do a
    Fabrice> malloc, and pass the resulting address to the function.
    Fabrice> But since the other function to manipulate the object
    Fabrice> only need the handle, I don't keep track of the memory I
    Fabrice> allocated.

    Fabrice> So who can I free the memory after the *_delete function
    Fabrice> ? Do I have to keep track of the memory allocation for
    Fabrice> each new object? Or can I simply assume that in fact the
    Fabrice> handle and the pointer are just the same thing (after a
    Fabrice> typecast) so I canjust do "free(my_handle)" ?

    Fabrice> It seems that it is the case at least for thread objects.

The expectation for a "typical" eCos application is that you work out
the number of threads, mutexes, ... that you are going to need and
allocate the memory for them statically. This is much preferred over
dynamic memory allocation: if there is not enough memory you find out
at link-time instead of run-time; it is not necessary to worry about
checking the result of every malloc() or similar operation and
figuring out how to recover when things go wrong; there is no
possibility of memory leaks.

Obviously not every application can fit into this mould. Looking at
the kernel's kapi.cxx file it seems to be very careful about
maintaining a one-one mapping between the supplied memory region and
the returned handle, so your assumption would seem to be safe for the
time being. I am not aware of any work in progress or being planned
which would force us to break this.

Bart Veer // eCos net maintainer