|flex/yacc--many multiple parsers in same program email@example.com (1996-05-13)|
|Re: flex/yacc--many multiple parsers in same program firstname.lastname@example.org (1996-05-14)|
|Re: flex/yacc--many multiple parsers in same program email@example.com (1996-05-19)|
|Re: flex/yacc--many multiple parsers in same program firstname.lastname@example.org (1996-05-19)|
|Re: flex/yacc--many multiple parsers in same program email@example.com (1996-05-19)|
|Re: flex/yacc--many multiple parsers in same program firstname.lastname@example.org (1996-05-19)|
|Re: flex/yacc--many multiple parsers in same program email@example.com (1996-05-19)|
|Date:||19 May 1996 14:17:24 -0400|
|Organization:||Parsepolis Software ("ParseCity")|
|Keywords:||lex, yacc, parallel|
> I'm looking to write a single interpreter that can simultaneously
> parse up to 96 separate programs. Due to other restraints in the
> program I cannot fork a process to handle each parser. What are my
> options using lex and yacc? It seems like a real hack to get either
> of them to handle more than one program.
I've implemented a C++ class hierarchy for an interpreted pattern matching
language that theoretically can create as many machines as memory will allow.
At the deepest levels of shared tables (there are a few static tables),
there will be some semaphore activity to avoid truly simultaneous memory
access during key phases, but for the most part, the processes of scanning,
parsing, and interpreting LPM are handled at the level of object
encapsulation, and therefore, each instantiated Lpm object can be viewed as
a virtual machine. This allows one to instantiate "arrays" of interpreters
as easily as:
I imagine that several strategies become possible in light of this.
Quinn Tyler Jackson
Parsepolis Software || Quinn Tyler Jackson
"ParseCity" || firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.