Jody:
I'm definitely going to do some more research on the fork-join framework.
Your idea of a "data first" approach versus a "thread first" approach seems
very interesting to me.
I like the idea of a simple feature collection that can accept processing
requests via the visitor pattern and then uses its own knowledge of its
members to apportion work to threads.
For example: I can envision an feature collection that maintains its own
thread pool. If it has 1000 features, it could assign threads to handle
processing requests on 100 features at a time. This would allow multiple
threads to modify the feature collection at the same time, for the same
processing request or for different processing requests. (Of course you
couldn't do this with threads that require aggregation on the feature
collection as a whole, such as counting the number of features with a
certain attribute value. To support that type of request, you'd need an
immutable copy of the feature collection at a "snapshot" in time.
These are all very interesting questions. Of course, my main goal with JUMP
Lib is to expose the best parts of the OpenJUMP core. I'm only going to
tackle thread support because it interests me and because it makes sense
for a geoprocessing library like the one I'm hoping to build.
Landon
On Thu, Jun 13, 2013 at 3:53 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
> Landon if you review the techniques for multi-threaded programming
> please provide feedback on what works for you. There are a number of ways
> to take a run at the problem and we are always interested in how to get
> things done.
>
> For example you may be able to answer some questions?
>
> Can Guava can be easily adapted to traversing a spatial index (and
> allowing each thread to take a different segments of a quad tree)?
> Look at GeoTrellis (here is a LocationTech Introduction to GeoTrellis
> video <http://www.locationtech.org/content/introduction-geotrellis>) and
> see how they attack things with a purely functional approach.
>
> And keep an eye on Java - in particular the Fork-Join JCP looks to be more
> friendly then the Callable / Future / Threadpool model we based GeoTools on.
> --
> Jody Garnett
>
> On Thursday, 13 June 2013 at 1:06 AM, Landon Blake wrote:
>
> Probably not a good fit then. There is probably license issues, and I want
> to stay away from the GeoTools feature model.
>
> OSGeo Labs it is then. :]
>
> Thanks.
>
> Landon
>
>
> On Tue, Jun 11, 2013 at 11:14 PM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
> On Wed, Jun 12, 2013 at 12:49 AM, Landon Blake <
> sunburned.surve...@gmail.com> wrote:
>
>
> Please share your thoughts with me. I'll consider the input from the
> Geotools community before I move forward. If hosting this code at Geotools
> is a bad idea, tell me. I won't get my feelings hurt. :]
>
>
> In order to be a GeoTools module it... hum... has to be using GeoTools :-)
> What I mean:
> * licence compatible, it has to be LGPL and don't have dependencies on
> libraries that have more restrictive licences (e.g., GPL)
> * using GeoTools features and feature collections (if we are talking
> vector data) or coverages (if we are talking raster data)
> * likely be using the geotools process API (stand alone classes are fine,
> classes that do implement an external processing api maybe not, but we can
> discuss it)
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
