Re: reentrancy

[Laurence Finston]

Thanks for the tip.  I've now tried out Flex 2.5.31, and the reentrant
C scanner does indeed do what I'd like it to do.  However, I have a
couple of concerns:

Since my package is for distribution, and not just for myself, using
Flex 2.5.31 would mean that either its users would have to download
and install Flex 2.5.31, or I'd have to distribute Flex 2.5.31 with
GNU 3DLDF.

For this reason, I'm considering using the C++ scanner classes with
Flex 2.5.4.  However, both the old and the new manuals (which is a lot
easier to use than the old one!) state that they are experimental and
subject to change.  Could you tell me anything about how risky it
would be to use them, i.e., how likely is it that a new official
release would force me to do lots of work rewriting my scanner?

The most recent official release of Flex was 2.5.4 in 1996 and there's
a 2.5.4a from 1997 in the `flex' directory of the GNU servers.
2.5.4 is the version of Flex on the machines that I have access to
running Linux and Free BSD.

Are you and the other Flex developers planning to release a new
version soon, and could you tell me roughly when?

Thanks.

Laurence



On Fri, 12 Mar 2004, W. L. Estes wrote:

> For the moment, see http://lex.sourceforge.net/ for beta flex sources
> which do all the below and more.
>
> On Wednesday, 10 March 2004,17:45 +0100, Laurence Finston wrote:
>
> > Hello,
> >
> > I've started working on writing the input routine for GNU 3DLDF using Bison
> > and Flex.  Now I'd like use multiple processes, or possibly threads, for
> > reading from more than one file at a time.  Is there any way of making Flex
> > reentrant, aside from using it to generate a C++ scanner class?
> >
> > I wouldn't mind using a C++ scanner class, since 3DLDF is written in C++
> > anyway, except that the Flex manual indicates that this feature is
> > experimental, and I don't know how to get Bison to use an object of this 
> > class
> > rather than just calling `yylex()'.
> >
> > I've already changed the calling convention for `yylex()' in order to make
> > `yyparse()' reentrant, as described in the Bison manual, so the value of the
> > token and the location are no longer stored in global variables.  I believe 
> > it
> > will work to redefine `YYINPUT' so that it doesn't use `yyin' and pass the
> > `File*' as a parameter to `yylex()', but I don't know what other global
> > variables might be involved.
> >
> > I thought it might help to call `yylex()' something else, e.g., `lexscan()',
> > and define a `yylex()' in the Bison input file that wraps `lexscan()'.  
> > Then I
> > could make the calls to `lexscan()' atomic.  I think this would only work 
> > with
> > non-preemptive scheduling, though, and I do want it to be possible to use
> > threads with preemptive scheduling, or heavyweight processes.
> >
> > I'd really appreciate it if someone could help me with this.
> >
> > Laurence Finston
> >
> >
> > _______________________________________________
> > Help-flex mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/help-flex
>
> --
> Will Estes (address@hidden) 336-256-8324
> UNC Greensboro, Information Technology
>