[m-users.] MR_GC_free ?

[Volker Wysk]

Am Mittwoch, dem 08.11.2023 um 14:54 +0100 schrieb Volker Wysk:
> Am Donnerstag, dem 09.11.2023 um 00:33 +1100 schrieb Julien Fischer:
> > On Wed, 8 Nov 2023, Volker Wysk wrote:
> > 
> > > > MR_NEW and MR_free allocate and free memory using malloc() and free()
> > > > respectively, not with the GC.  It's safer to use the GC versions.
> > > > Additionally, foreign_procs that mix memory allocators, especially a
> > > > manual allocator, is likely be difficult to debug and maintain.
> > > 
> > > This leads me to the same question as Peter's answer: Can the garbage
> > > collector see inside a C structure, if it is allocated with MR_GC_NEW?
> > 
> > Yes it can.  Bear in mind that the Boehm GC is designed to be garbage
> > collector for C; so far as it is concerned there is no distinction
> > between Mercury and C data structures.
> 
> I'm wondering how it can, but okay. 
> 
> There's the ODBC library, which I'm trying to make thread-safe. I want to
> package the former global variables in a new structure like this:
> 
> typedef struct {
>     MR_jmp_buf odbc_trans_jmp_buf;
>     SQLHENV odbc_env_handle;
>     SQLHDBC odbc_connection;
>     SQLRETURN odbc_ret_code;
>     MR_Word odbc_message_list;
> } MODBC_Global;
> 
> The pointer to this data is to be passed to all the procedures, which used
> the global variables before. 
> 
> Now, there are two ODBC handles in this structure: odbc_env_handle and
> odbc_connection. These are just pointers. But they should NOT be deallocated
> by the garbage collector. They need to be freed by the relevant ODBC
> "SQLFree..." procedure.
> 
> So, I think I should allocate/release the MODBC_Global explicitly with
> MR_NEW /MR_free. Is that correct?

I think I know the answer: The ODBC handles won't be garbage collected,
because they haven't been specially allocated with the garbage collector.
This means, I can allocate the MODBC_Global with MR_GC_NEW and free it with
MR_GC_free.

Cheers,
Volker