Re: [Tinycc-devel] make tcc reentrant

[Michael Matz]

Hello,

On Mon, 9 Dec 2019, Ulrich Schmidt wrote:

> Am 09.12.2019 um 16:42 schrieb Michael Matz:
> > And here's the crux: define "compiling state related values".  Is the
> > memory allocator part of that?  The token hash table?  The sections?
> > The symbol table?  Do all of those really need to become per-state?  Do we
> > really need to support multi-threading at a finer grain level than a BCL
> > (big compiler lock:)  )?
> 
> compiling state related values:
>   All values changable betwen tcc_new() call and tcc_delete() call.

Only those explicitely changable via API calls, or those changed 
internally as well?  I guess you mean the former, then it follows that 
e.g. the token hash table and internal memory allocator can remain shared, 
as can the expr evaluation stack and many parts of the code generator 
(always with the mental model that the API calls serialize).

Symbol table and sections would be border line, as those can be influenced 
by what you throw into tcc_compile_string.  I guess you would want to be 
able to have two states s1 and s2, and define two different 'main' 
functions in the two states, right?  I think that and similar things can 
be accomplished without triggering any of the concerns I have with the 
fully-reentrant-fine-grained solution.

You mentioned that you had to add many TCCState arguments merely for the 
sake of tcc_error.  Would it perhaps be enough for you to register only a 
single error callback function if it were given the 'current' TCCState 
magically?  (I'm thinking of a solution where the API calls, which already 
always get a TCCState would act as critical sections and therefor could 
overwrite/restore the global tcc_state variable, and thereby reduce the 
syntactic impact of these changes)


Ciao,
Michael.