[m-users.] Global variables that are local to the thread

[Peter Wang]

On Mon, 06 Nov 2023 16:04:10 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> 
> On Sun, 5 Nov 2023, Volker Wysk wrote:
> 
> > I'm considering to build a new version of the ODBC library, that's thread-
> > safe. There's a point which I don't understand yet.
> >
> > The ODBC library has a number of global variables. For instance, the ODBC
> > environment handle. This makes it thread-unsafe. 
> >
> > Can these variables be made local to the thread, while still being global,
> > so all foreign procedures in the same thread can access it? Or do I need to
> > introduce a new argument of some new type odbc_data, which is to be passed
> > to all predicates of the library? This type would hold all the formerly
> > global data, but it would be burdensome to pass it around all the time.
> 
> Either approach could work. Personally, I would pass the extras
> infromation to all the predicates and avoid global state at all.
> >

Agreed.

> > Maybe use a thread-local mutable variable?
> 
> You could use a thread-local mutable; I note that the reference manual
> doesn't currently talk about how to access the value of a thread-local
> mutable from C code.  (It's done using the
> MR_{get,set}_thread_local_mutable macros in runtime/mercury_thread.h.)

I would consider those to be implementation details - use at your own
risk (of your program not compiling the future). You can access a
thread-local mutable from Mercury code, and just hand the value to a
foreign proc.

Peter