Re: [Tinycc-devel] make tcc reentrant

[uso ewin]

Hello,

I've made a version that should support multi thread on my github
https://github.com/cosmo-ray/tcc/commit/46d0e73edc7e448f0f514936fdb4f62e2c8800a4
I didn't tests it, it's just here to show the
possibility using _Thread_local.

This approach even if it doesn't enable reentrancy,
allow multy-thread, can be disable
and doesn't modify a lot of code.

Do you think you could use that Ulrich ?

Thanks,
Matthias

On Sat, Dec 7, 2019 at 12:51 PM Daniel Glöckner <address@hidden> wrote:
>
> Hi,
>
> On Sat, Dec 07, 2019 at 11:34:11AM +0100, Ulrich Schmidt wrote:
> > - The in scenario1 unloved 1 function parameter can be ignored and the
> > values stored locally:
> >   #define LIBPARAM1
> >   #define VALUE(v) v
> >   ..
> >
> >   somereturn somefunc(LIBPARAM1 ...) {
> >     VALUE(count) = 0;
> >     ...
> >
> > - in scenario 2 we define the 2 macros different:
> >   #define LIBPARAM1 TCCState *s1,
> >   #define VALUE(v) s1->v
>
> We need a macro
>
> #if scenario == 1
> #define PASSPARAM1
> #else
> #define PASSPARAM1 s1,
> #endif
>
> Grouping all globals in the TCCState structure might be beneficial
> even if we don't switch to those macros, because of the cache locality
> Christian wrote about. The VALUE macro in scenario 1 would then be
> #define VALUE(v) global_state.v
>
> Btw, has anyone thought about handling TCCState like the context is
> handled in the OpenGL API? It has one function to select the context
> to use for following operations and the operations themselves don't
> have a parameter for the context. If the pointer to the TCCState is
> stored in a normal or in a TLS variable is up to us and might even
> be a compile time option (that is set to "normal" for compilation
> with tcc as long as tcc doesn't know how to generate TLS variables).
>
> Best regards,
>
>   Daniel
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel