[mapserver-dev] RFC 64 - Call for a vote...

Tamas Szekeres szekerest at gmail.com
Mon Nov 29 13:59:35 EST 2010


Steve,

I just wanted to make sure whether a thread safe approach of passing in
stuff to the parser is doable at this stage or not? By looking a the
proposed mapparser.y it doesn't seem to be implemented with the current
version. I recall Frank has suggested to take a look into the recent parser
enhancement in gdal with a reasonable approach:
http://trac.osgeo.org/gdal/browser/sandbox/warmerdam/gdal-rfc28/gdal/ogr/swq_parser.y

In case if we follow this version would this be such a big deal (and require
to wait for a subsequent major release) if we would want to switch to a
thread safe implementation in the future?

Do we have any reason to alter the original RFC number from 59 to 64?


Best regards,

Tamas




2010/11/29 Lime, Steve D (DNR) <Steve.Lime at state.mn.us>

> It's been a week with little comment, not sure how that should be
> interpreted. I know it's a long RFC. I feel a little uncomfortable declaring
> it "passed" based on only two votes though.
>
> Steve
>
> -----Original Message-----
> From: mapserver-dev-bounces at lists.osgeo.org [mailto:
> mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Lime, Steve D (DNR)
> Sent: Monday, November 22, 2010 11:38 AM
> To: Stephen Woodbridge; mapserver-dev at lists.osgeo.org
> Subject: RE: [mapserver-dev] RFC 64 - Call for a vote...
>
> 1) Thread safety. At the moment I use thread locks as we always have. So
> there's no regression there. I'd like to try and make things thread safe (at
> least for parser, as opposed to flex for mapfiles) for 6.0.
>
> 2) I would like to push the IN operator optimization off (unless someone is
> motivated now). I don't think it's trivial exercise since we need to support
> both string and numeric lists on the right-hand side.
>
> Steve
>
> -----Original Message-----
> From: mapserver-dev-bounces at lists.osgeo.org [mailto:
> mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge
> Sent: Monday, November 22, 2010 11:19 AM
> To: mapserver-dev at lists.osgeo.org
> Subject: Re: [mapserver-dev] RFC 64 - Call for a vote...
>
> On 11/22/2010 11:39 AM, Lime, Steve D (DNR) wrote:
> > Need to act on RFC 64 one way or another so I'll call for a vote.
> >
> > http://mapserver.org/development/rfc/ms-rfc-64.html
>
> Steve,
>
> What are you thoughts on the TODO list? Are these getting pushed out
> post 6.0?
>
> Are you planning to put thread locks around the parser global usage so
> you don not break thread safety? As opposed to making the code thread
> safe now? I do not think you can regress thread-safety and break that.
>
> For the IN optimization, if the IN list is large, load the tokens into a
> btree structure and search will be very fast. I believe this is how
> postgres does it internally.
>
> Unless there are some serious concerns from others on issues I'm not
> seeing, this seems like a huge amount of value for relatively low risk,
> other than changing a lot of code. I think this needs to go into 6.0.
>
> +1 for 6.0
>
> -Steve W
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20101129/96d2079c/attachment.html


More information about the mapserver-dev mailing list