[Gdal-dev] Re: Error handler threading suggestion

[Chris G. Nicholas]

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


-----Original Message-----
From:	gdal-dev-bounces at lists.maptools.org on behalf of Frank Warmerdam
Sent:	Mon 7/25/2005 10:49 AM
To:	Steve Soule
Cc:	gdal-dev at lists.maptools.org
Subject:	[Gdal-dev] Re: Error handler threading suggestion
On 7/21/05, Steve Soule <Steve.Soule at vexcel.com> wrote:
> Currently, the GDAL error handler is thread-local.  If the client wants
> the error handler to be something other than CPLDefaultErrorHandler,
> CPLSetErrorHandler must be called by each thread created.  This is
> painful.
> 
> Currently there is an error-handler stack, maintained as
> psHandlerStack, with pfnErrorHandler implicitly the top of the
> stack.  CPLPushErrorHandler and CPLPopErrorHandler maintain the stack,
> and CPLSetErrorHandler replaces the top handler on the stack.  The stack
> must be thread-local, because push and pop are used to temporarily turn
> off error reporting in many places in GDAL.  It would be nice if
> CPLSetErrorHandler set the handler for all threads.
> 
> Here's how to do it:  let pfnErrorHandler implicitly be the bottom
> of the stack instead of the top of the stack.  Push and Pop would
> not change pfnErrorHandler.  The two places the error handler is
> called, CPLErrorV and CPLDebug, would be changed to check the stack
> first, and call the top handler on the stack if the stack were not
> empty, and only call pfnErrorHandler if the stack were empty.
> Then pfnErrorHandler would not need to be thread-local, and
> CPLSetErrorHandler would set the base error handler for all threads.
> CPLPushErrorHandler and CPLPopErrorHandler would override the base
> error handler for a single thread.

Steve,

I agree.  I have changed the model as you suggest, and now
the "error handler stack" is thread-local and takes precidence over
error handlers installed with CPLSetErrorHandler().  The handler
installed with CPLSetErrorHandler() is global to all threads. 

In single threaded applications this does potentially mean there is 
a change in how error handlers work in some applications.  In particular,
you can no longer be confident that CPLSetErrorHandler() will change
the error handler that will be used for the next error.  If there have
been error handlers pushed with CPLPushErrorHandler() then these
will take precidence.   However, I think this is a rare circumstance. 

I have updated the documentation accordingly.

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

_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev

!DSPAM:42e527a1243531288513109!