|Lex/Yacc and multi-thread firstname.lastname@example.org (Zixiong WANg) (1997-12-12)|
|Re: Lex/Yacc and multi-thread email@example.com (1998-01-05)|
|From:||firstname.lastname@example.org (Jon Hornstein)|
|Date:||5 Jan 1998 13:15:42 -0500|
"Zixiong WANg" <email@example.com> wrote:
> Lex and Yacc use a lot of global variables to communicate to each
>other, this makes them no safe in a multi-threading program.
> The same thing applies to Flex/Bison (gnu Lex/Yacc).
> Is there a solution to this ?
>[There's a reentrant option for bison. -John]
I didn't tackle the problem from that perspective. I wanted a
mutilthreaded interpreter so what I did I "compiled" to parsing
elements a tree that was interpretable.
I streamed the parse tree to a file using ObjectSpace streaming
The "compilation" was done, I didn't need to LEX/YACC again.
So by having a compile step to create the parse tree I didn't need to
embed the parser and lexical analyser into my application.
Stoing the results of parsing the processed language in a file which
could be streamed in later, I got a form of "reentrant" lex/yacc
parsing at runtime. The data structures were quite large but so was
the UNIX system I worked on.
Each request would now look in an object cache (stl map) if the object
wasn't in the cache I streamed it into the cache.
I would then get pointer to the parse tree. Note the tree was always
owned by the cache. The interpreter engine could only read the nodes.
Each instance of the interpreter class would create it's own symbol
table, variable stack (virtual machine) etc.
Hope it helps.
Return to the
Search the comp.compilers archives again.