public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] handle and structures
@ 2000-08-18 16:46 Fabrice Gautier
  2000-08-21 11:35 ` Bart Veer
  0 siblings, 1 reply; 2+ messages in thread
From: Fabrice Gautier @ 2000-08-18 16:46 UTC (permalink / raw)
  To: Ecos-List (E-mail)

Hi,

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

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

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

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

Thanks

A+

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ECOS] handle and structures
  2000-08-18 16:46 [ECOS] handle and structures Fabrice Gautier
@ 2000-08-21 11:35 ` Bart Veer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Veer @ 2000-08-21 11:35 UTC (permalink / raw)
  To: Fabrice_Gautier; +Cc: ecos-discuss

>>>>> "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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2000-08-21 11:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-18 16:46 [ECOS] handle and structures Fabrice Gautier
2000-08-21 11:35 ` Bart Veer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).