[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] make tcc reentrant
From: |
Michael Matz |
Subject: |
Re: [Tinycc-devel] make tcc reentrant |
Date: |
Mon, 9 Dec 2019 17:25:13 +0000 (UTC) |
User-agent: |
Alpine 2.21 (LSU 202 2017-01-01) |
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.
- Re: [Tinycc-devel] make tcc reentrant, (continued)
- Re: [Tinycc-devel] make tcc reentrant, Charles Lohr, 2019/12/06
- Re: [Tinycc-devel] make tcc reentrant, Domingo Alvarez Duarte, 2019/12/07
- Re: [Tinycc-devel] make tcc reentrant, Ulrich Schmidt, 2019/12/07
- Re: [Tinycc-devel] make tcc reentrant, Daniel Glöckner, 2019/12/07
- Re: [Tinycc-devel] make tcc reentrant, uso ewin, 2019/12/08
- Re: [Tinycc-devel] make tcc reentrant, Ulrich Schmidt, 2019/12/08
- Re: [Tinycc-devel] make tcc reentrant, Michael Matz, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, Michael Matz, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, Michael Matz, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, Ulrich Schmidt, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant,
Michael Matz <=
Re: [Tinycc-devel] make tcc reentrant, grischka, 2019/12/06
Re: [Tinycc-devel] make tcc reentrant, Christian Jullien, 2019/12/07
- Re: [Tinycc-devel] make tcc reentrant, Michael Matz, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, Domingo Alvarez Duarte, 2019/12/09
- Re: [Tinycc-devel] make tcc reentrant, ag, 2019/12/10
- Re: [Tinycc-devel] make tcc reentrant, Forrest Curo, 2019/12/10
- Re: [Tinycc-devel] make tcc reentrant, grischka, 2019/12/10
- Re: [Tinycc-devel] make libtcc reentrant, Ulrich Schmidt, 2019/12/11
- Re: [Tinycc-devel] make libtcc reentrant, grischka, 2019/12/11
- Re: [Tinycc-devel] make libtcc reentrant, Karl Yerkes, 2019/12/11