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. _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
