Hello Dana!
03.03.2017 18:57, Dana Robinson пишет:
I'll create an issue for this. We have a Windows layer that substitutes Win32
equivalents for some POSIX commands and it should be straightforward to use
SetEnvironmentVariable() on Windows.
I'm not sure whether this issue is in fact specific for Windows.
On one hand, on POSIX system getenv also uses cached values
(But is there a way to modify env.variables other than through setenv?)
On the other hand, POSIX culture of application deployment differs much
from that of Windows, and distributing plugins in a local dir is
probably not what people would actually like to do.
A simple (but probably incorrect) way to fix the issue if it's
considered Windows-specific would be to define HDgetenv via
GetEnvironmentVariable.
Best wishes,
Andrey Paramonov
-----Original Message-----
From: Hdf-forum [mailto:[email protected]] On Behalf Of
?????? ?????????
Sent: Friday, March 3, 2017 3:43 AM
To: HDF Users Discussion List <[email protected]>
Subject: [Hdf-forum] Setting plugin path programmatically
Hello!
My usage scenario is a big Windows application with a lot of dlls, some of
which use HDF5 library. HDF5 code uses Dynamically Loaded Plugin Filters:
https://support.hdfgroup.org/HDF5/doc1.8/Advanced/DynamicallyLoadedFilters/HDF5DynamicallyLoadedFilters.pdf
The filters are deployed in a local directory which is activated via modifying
process HDF5_PLUGIN_PATH env.variable, just prior to loading the library. That
works fine, and important thing is that user can just drop new plugins in that
directory to support newer files.
However, it appears that in some cases plugin search fails. HDF5 library
retrieves HDF5_PLUGIN_PATH via HDgetenv which is defined as
#define HDgetenv(S) getenv(S)
According to
http://stackoverflow.com/questions/10636768/does-getenv-cache-the-result/10636993#10636993
"A process inherits the environment from the process creating the new process. This
is held in memory."
In the application I do not use C runtime (the implementation language is not
C), so I use SetEnvironmentVariable:
https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms686206(v=vs.85).aspx
It appears that if I modify HDF5_PLUGIN_PATH before C runtime is loaded for the
first time in the application, all is fine. However if I call
SetEnvironmentVariable after C runtime is already loaded, it has no effect for
HDF5.
The application is huge, and it's very hard to control the moments C runtime
and HDF5 library are loaded. I wonder -- does it make sense to add HDF5
procedures to verbosely modify plugin search path, something like
herr_t H5PLadd_path(const char *name)
herr_t H5PLrem_path(const char *name)
?
The above procedures could use HDsetenv, which is otherwise not accessible
(from non-C applications).
(I think similar motivation led to exposing H5free_memory procedure.)
What do you think?
Best wishes,
Andrey Paramonov
--
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
