asynchronous i/o with lex/yacc (or flex/bison)?

sgendler@akamai.com
28 Sep 2000 17:40:45 -0400

          From comp.compilers

Related articles
asynchronous i/o with lex/yacc (or flex/bison)? sgendler@akamai.com (2000-09-28)
| List of all articles for this month |

From: sgendler@akamai.com
Newsgroups: comp.compilers
Date: 28 Sep 2000 17:40:45 -0400
Organization: Deja.com - Before you buy.
Keywords: parallel, question, comment

I am working on a project which is utilizing asynchronous i/o model in
order to maximize network throughput. Unfortunately, our homegrown
parser is not sufficient for the feature set we have envisioned. We
have decided to move to lex/yacc (flex/bison) to implement the updated
parser. However, currently we are able to parse a source object as it
arrives, buffer by buffer. Using lex and yacc as is, they expect
blocking i/o calls. Is it possible to modify (hopefully easily) both
lex and yacc to handle asynchronous i/o. This is a single threaded
application, so siting in a loop on EAGAIN is not an option. The
lexer/parser must be able to return in the middle of the parsing
process, and then reenter, and pick up state where it left off.


The language we are parsing is valid xml, so I could work out a method
of marking the start of each tag by just marking the offset whenever we
encounter a '<' character in the correct context. We could just reparse,
starting at the last '<' every time we execute a read, until we
encounter the '>' in the correct (close tag) context. However, this is
ugly and will add a lot of complexity, not to mention tons of
backtracking, potentially. Suggestions for alternatives would
be greatly appreciated.


I should add that I am a total lex and yacc novice, although I have
ready access to folks who have done significant work with them, although
in every case, it was some years ago...


Thanks in advance.


(please cc my email address, )


--sam
[It's certainly doable, although not pretty. People have hacked up both
lex and yacc to be reentrant, which is a start. -John]


Post a followup to this message

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