Thanks, that does make sense. Fortunately, like py, Rust also has closures, so user data could be handled directly by the caller. We're also pushing for an impl. without user-data support. The thread local APIs should also be supported (not done yet though); should be much simpler as it doesn't involve concurrency.
On Sun, Sep 12, 2021 at 9:53 PM Sean Gillies <[email protected]> wrote: > 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 <[email protected]> > 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 >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
