Revisiting parrot_get_config_string
Nick Glencross
I shall shortly update the relevant calls, but I'd just like to check
a few things first.
These patches update the patches in #37303 and #36836, relating to
parrot_get_config_string and cygwin dynclasses.
The first patch modifies the parrot VM so as not to call
parrot_get_config_string on startup, which currently resides in the
calling executable. Instead, the executable (optionally) calls
Parrot_set_config_hash to set the config environment.
A couple of questions arise:
* Currently only the interpreter that is explicitly created by the
application will have configuration settings. What's the best way to
make sure that each interpreter will have access to it? Will future
Interpreters clone the environment, or will it explicitly need to be
set on each new interpreter? (If need be, I can preserve the hash in
the VM and seed future interpreters with it)
* The function call parrot_get_config_hash is shared between the
*_config.o object files and the calling executable (but *not* the VM
itself). What's the most suitable header file to declare it in?
There was talk the other day about whether install_config.o needed to
be distributed in a dev distribution, and while the answer is still
yes, after these changes it becomes up to the application as to
whether it needs to link with it.
A solution to the dynclasses on cygwin (and mingw?) [#36836] issue
becomes possible with these patches, and yesterday's shared library
work. Since (as far as I'm aware) cygwin doesn't have rpath
functionality, it is necessary to add blib/lib to the PATH for it to
find the parrot DLL.
Cheers,
Nick
Leopold Toetsch
> Guys,
>
> I shall shortly update the relevant calls, but I'd just like to check
> a few things first.
>
> These patches update the patches in #37303 and #36836, relating to
> parrot_get_config_string and cygwin dynclasses.
>
> The first patch modifies the parrot VM so as not to call
> parrot_get_config_string on startup, which currently resides in the
> calling executable. Instead, the executable (optionally) calls
> Parrot_set_config_hash to set the config environment.
Looks good.
> A couple of questions arise:
>
> * Currently only the interpreter that is explicitly created by the
> application will have configuration settings. What's the best way to
> make sure that each interpreter will have access to it? Will future
> Interpreters clone the environment, or will it explicitly need to be
> set on each new interpreter? (If need be, I can preserve the hash in
> the VM and seed future interpreters with it)
This question of course arises with a lot more interpreter structures,
the config hash is just one of these. For the config hash my answer is:
config is read-only, non-mutable, therefore it should be created as a
constant, read-only hash, which of course means that keys and values are
also constant and read-only.
The little problem is that we don't have interfaces yet and the
necessary API calls, to create such a hash. Anyway, read-only items can
easily be shared between multiple interpreters and threads.
> * The function call parrot_get_config_hash is shared between the
> *_config.o object files and the calling executable (but *not* the VM
> itself). What's the most suitable header file to declare it in?
There should be just one API call ...
Parrot_set_config_hash (interpreter);
... which calls parrot_get_config_* [1], the prototype should be in embed.h.
[1] It's probably simpler to just return the config bytes and the
length, so that parrot_config.c doesn't need any parrot headers (which
possibly pull in some extern globals like _environ).
That is Parrot_set_config_hash() calls parrot_get_config_bytes, converts
to string, thaws it and sets the config hash.
> There was talk the other day about whether install_config.o needed to
> be distributed in a dev distribution, and while the answer is still
> yes, after these changes it becomes up to the application as to
> whether it needs to link with it.
Good.
> A solution to the dynclasses on cygwin (and mingw?) [#36836] issue
> becomes possible with these patches, and yesterday's shared library
> work. Since (as far as I'm aware) cygwin doesn't have rpath
> functionality, it is necessary to add blib/lib to the PATH for it to
> find the parrot DLL.
Or set LD_LIBRARY_PATH ?
> Cheers,
>
> Nick
leo
Nick Glencross
>
> Nick Glencross wrote:
> > The first patch modifies the parrot VM so as not to call
> > parrot_get_config_string on startup, which currently resides in the
> > calling executable. Instead, the executable (optionally) calls
> > Parrot_set_config_hash to set the config environment.
>
> Looks good.
Thanks. As an aside, I noticed that Darwin was initially a bit funny about
this yesterday, but managed to overcome it with a linker flag.
> A couple of questions arise:
> > <snip...>
>
>
> * The function call parrot_get_config_hash is shared between the
> > *_config.o object files and the calling executable (but *not* the VM
> > itself). What's the most suitable header file to declare it in?
>
> There should be just one API call ...
>
> Parrot_set_config_hash (interpreter);
>
> ... which calls parrot_get_config_* [1], the prototype should be in
> embed.h.
Ah, but that's reverting it back to how it was, as the parrot VM is calling
back out again to a function in user code.
I certainly considered having the *_config.c files continue to return the
config bytes, but this felt nicer to me.
How about I meet you half way:
* The *_config.c files give access to the config bytes
* The harness calls the VM with the bytes (which can now be done before
the interpreter starts up)
* The VM records a pointer to the bytes (and length)
* When an interpreter starts, it can either create its own hash, or refer
to one hanging off another interpreter (whichever model ends up being used)
> Since (as far as I'm aware) cygwin doesn't have rpath
> > functionality, it is necessary to add blib/lib to the PATH for it to
> > find the parrot DLL.
>
> Or set LD_LIBRARY_PATH ?
LD_LIBRARY_PATH is used by dlopen, but not for DLLs that you are directly
linked against by the looks of it.
I'll cut another patch when I've made some changes...
Nick