Re: Lex/Yacc and multi-thread

"Zixiong WANg" <zi@spidernet.tm.fr> wrote:


>Hi,


> 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 ?


> Thanks.
>[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
facility.


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.


Jon
--

Return to the comp.compilers page.
Search the comp.compilers archives again.