[gdal-dev] Get error handler user data when removing CPL Error Handler
Even Rouault
even.rouault at spatialys.com
Sun Sep 12 07:12:19 PDT 2021
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
> <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
> <https://github.com/georust/gdal/pull/215>
>
> -
> Regards
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210912/a1407600/attachment.html>
More information about the gdal-dev
mailing list