[Mapserver-dev] Reentrant flex scanner

[Steve Lime]

You can wrap it however you want but it still needs to be accessible.
Maybe
the idea of cloning mapObjs, which in turn could contain a scannerObj
makes
a lot of sense as a model.

The expression code is where is has to be, accessed as features are.
It's
just not close to where people normally interact with the API... I do
want
to update the expressions but not because of threading, but the
availability
of something like GEOS.

Steve

>>> Sean Gillies <sgillies at frii.com> 7/8/2004 3:09:25 PM >>>
Steve,

Let's make the scanner an object like the others.  I guess it would
be sorta like the errorObj, one (usually) per thread?

Refactoring is essential for mapserver's long term viability.  The
way expressions are buried is more an argument *for* change than an
argument against.  IMO.

Sean

On Jul 8, 2004, at 1:52 PM, Steve Lime wrote:

> That's basically what flex gives you, plus a bunch of functions to
> get and set values from that structure. Bison also has the
capability
> but
> I've not researched it though. I think the flex is the tougher nut
to
> crack.
>
> There's still a problem of where to house this/these structures.
They
> would
> need to be thread based and not tied to a mapObj. (This is new
> territory for
> me.) Would the scanner have to be initalized by an application and
then
> passed
> into msLoadMap and any other functions that ultimately deal with
> expressions?
> That would be pretty simple for reading the mapfile, but expression
> evaluation
> is buried deep the bowels of the code.
>
> Steve
>
>>>> Sean Gillies <sgillies at frii.com> 7/8/2004 1:02:20 PM >>>
>
> On Jul 8, 2004, at 11:26 AM, Steve Lime wrote:
>
>> Hi Folks: I've been a bit of reading, and have discovered that flex
> can
>> (as of when I'm not sure) generate a reentrant and apparently
>> thread-safe C scanner. Has anyone used that API? How easy or hard
is
> it
>> to port an application that uses non-reentrant scanner?
>>
>> Steve
>
> Steve, I spent last sunday researching this as well.  Could be as
> simple
> as keeping the parser data in a struct for each thread instead of
> using
> globals, right?
>
> Sean
>
> --
> Sean Gillies
> sgillies at frii dot com
> http://users.frii.com/sgillies 
>