[ENet-discuss] 1.0 imminent - any requests?

[Lee Salzman]

I think I addressed the connection/disconnection stuff as well as
tweaked the timeout limit in CVS (it should be half of what it was), 
but am still wavering on what to do about memory management.

What interface would you suggest for specifying the memory allocator?

I was just thinking so far to have a structure holding some user data
plus stubs for malloc, calloc, realloc, and free (with sensible defaults
for calloc and realloc), and maybe passing it into enet_initialize or
maybe some other function. Not terribly sure yet.

Here's an example of what I was thinking:

typedef struct
{
  void * data;
  void (* malloc) (void * data, size_t size);
  void (* free) (void * data, void * memory);
  /* calloc and realloc may be NULL and by default will be implemented in terms of
   * malloc and free.
   */
  void (* calloc) (void * data, size_t nmemb, size_t size);
  void (* realloc) (void * data, void * memory, size_t size);
} ENetMemoryAllocator;

// Configure the memory management policy.
void enet_memory_allocator_configure (const ENetMemoryAllocator *);

Is this okay with everyone or would you guys like something friendlier
than this? I am almost thinking of not even allowing calloc/realloc to
be specified just because they are used in so few places in the source
code that specialized implementations are totally unnecessary. 

On Tue, Dec 23, 2003 at 12:26:19PM -0500, Brian Hook wrote:
> > - ENET use a dynamic memory allocation scheme for incoming/outgoing
> > packet handling.
> 
> I'll re-add my request that the memory management in ENET be revamped 
> to allow for user-defined allocators.  The existing implementation 
> works fine as a default implementation, but I believe a lot of 
> real-world implementations will end up having to hack the source in 
> order to make it work within their constraints.
> 
> Brian
>