Re: Problems using bison and flex with C++

[Laurence Finston]

-------------------
Hans Aberg wrote:
> At 20:55 +0200 2004/06/25, Laurence Finston wrote:
> >I've been assuming that the parser stack is also local to `yyparse()' when
> >one generates a reentrant parser.  I've been planning to call `yyparse()'
> >multiple times in multiple threads to read multiple input files. I haven't
> >tried
> >this out yet, and I've now rechecked the Bison manual, but haven't found
> >anything to support this assumption.  Could somebody tell me whether it's
> >correct?
> 
> The best way to find out is to look into the parser .c-file that Bison
> outputs. I think that most likely, the stacks are not in the
> parser-function.

Thanks for the information. I won't be able to check this until Monday, but I
strongly suspect you're right, which means trouble for me.  

> 
> Under C++, one can distinguish between the stacks being class-local and
> function-local: Bison writes a C++ parser class, which contains a parser
> function. Currently, the stack is put in the class, not the
> parser-function. So it is class-local, but not function-local, and if
> multiple stacks are needed, one will have to generate a new class
> instantiation for each one. So, since this C++ parser derives from the
> C-parser, I think that the C-parser stack is not function local, but
> C-global, then.
> 

> I think this issue is a development issue, to be addressed in the Bug-Bison
> list, then. If you make a C-version that is completely thread safe, you may
> submit it for use in the Bison distribution (it is not difficult to rewrite
> a Bison skeleton file). Perhaps Paul Eggert (cc'ed) knows more about this
> issue.
> 

>   Hans Aberg

I assume you mean the patch you mentioned in a previous posting, since the
Bison manual doesn't mention a C++ parser class.  Thanks for the suggestion,
but I don't want GNU 3DLDF to require any non-standard features for the tools
needed to build it.  Therefore I don't want to use beta-versions, patches, or
custom skeleton files.  Nor do I want to get into writing patches or skeleton
files myself --- I'm happy to just be a user of Bison.

I think "bug" mailing lists are for bugs only, and that the "help" list is
most appropriate for discussions about development issues, since there doesn't
seem to be a public list especially for them.  However, I will defer to the
opinion of the maintainers, if they have one.

Do the Bison maintainers have any plans to make multiple invocations of
`yyparse()' thread-safe, assuming they aren't already? 
If so, will it be within the next few months?

I can get around the problem for now by using processes instead of threads,
but that's very wasteful of resources, and in the long run I will have to find
a better solution. 

Laurence