[Gdal-dev] Re: Error handler threading suggestion

Chris G. Nicholas cgn at globexplorer.com
Mon Jul 25 17:33:42 EDT 2005


For apps that can tolerate a few seconds of delay (i.e. aren't inline serving web users users with a very short attention span) I highly recommend the stuff of: http://gridengine.sunsource.net/ . We run this against 100+ CPUs all the time; works great. The other choice is: http://www.cs.wisc.edu/condor/ .

Simpler approaches are good old fork/exec based on inetd; you can use simple load balacing stuff in Apache, or use the Linux stuff of: http://lcic.org/load_balancing.html . We use this all over too...

Chris

-----Original Message-----
From:	Frank Warmerdam [mailto:fwarmerdam at gmail.com]
Sent:	Mon 7/25/2005 2:06 PM
To:	Chris G. Nicholas
Cc:	gdal-dev at lists.maptools.org
Subject:	Re: [Gdal-dev] Re: Error handler threading suggestion
On 7/25/05, Chris G. Nicholas <cgn at globexplorer.com> wrote:
> In what multithreaded scenarios do people actually envision using GDAL? Is this all about FastCGI?
> 
> Or are people on a quest to make the CPU and I/O intensive routines of GDAL truly multithreaded, in the sense that they might scale linearly with available resources? (of course, subject to underlying library restrictions of things like ECW, MrSid, Kakadu, Proj4, etc etc)

Chris, 

I can't speak for everyone, but the intent is to implement a server of
some sort that can have multiple threads active reading from a variety of
files with some degree of scalability.   

In some cases folks aren't as concerned about the scalability of GDAL
and ensuring that it can be safely used in existing multi-threaded
applications.  

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

!DSPAM:42e55493275991938320547!










More information about the Gdal-dev mailing list