[gdal-dev] Get error handler user data when removing CPL Error Handler
Sean Gillies
sean at mapbox.com
Sun Sep 12 09:23:15 PDT 2021
Hi,
For what it's worth, In the Python package named rasterio we're using the
push/pop API:
https://github.com/mapbox/rasterio/blob/master/rasterio/_env.pyx#L336.
While Rust's needs may differ, a single handler without any support for
user data works well for Python: everything goes to the logging
infrastructure, one of the kind of globals that Howard refers to in
https://github.com/OSGeo/gdal/blob/master/gdal/doc/source/development/rfc/rfc37_cplerror_userdata.rst#rationale,
and Python developers extend the logger if they want behavior that is
different from the basic defaults.
On Sun, Sep 12, 2021 at 8:12 AM Even Rouault <even.rouault at spatialys.com>
wrote:
> Hi,
>
> no there's no thread safe API to do what you want. You'd need a new
> function
>
> CPLErrorHandler CPLSetErrorHandlerEx2( CPLErrorHandler pfnErrorHandlerNew,
> void* pUserData, void** ppOldUserData )
>
> to do that.
>
> But as you mention threads that might compete to set an error handler,
> using CPLSetErrorHandlerEx() is probably not the best strategy. You'd be
> better with CPLPushErrorHandler() / CPLPopErrorHandler() that only affects
> the current thread.
>
> Even
> Le 12/09/2021 à 16:03, Rajsekar Manokaran a écrit :
>
> Hi,
>
> In the gdal rust bindings (https://github.com/georust/gdal), we're trying
> to facilitate the use of CPLSetErrorHandlerEx and related APIs. While
> setting a handler, we may pass a heap allocated data pointer to the second
> argument, which is then read via the CPLGetErrorHandlerUserData in the
> handler and passed to the user.
>
> However, while removing or setting another handler, we're unable to find a
> race-free method to get the associated user data of the previous handler.
> This is needed to properly deallocate the memory.
>
> Is there an atomic way to get both the previous handler (as returned by
> CPLSetErrorHandler), along with the associated user data? The issue with
> making two calls, is that another thread might make changes in between the
> two calls.
>
> We could synchronize in our API, but it still has the same issue if the
> user parallely used the C APIs directly or via a different interface.
>
> Relevant PR in rust gdal bindings:
> https://github.com/georust/gdal/pull/215
>
> -
> Regards
>
>
--
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210912/cef13953/attachment-0001.html>
More information about the gdal-dev
mailing list