|James E Keenan on 13 Feb 2019 22:05:43 -0800|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|[Philadelphia-pm] Fwd: [perl #133737] Build-time failures with PERL_GLOBAL_STRUCT and PERL_GLOBAL_STRUCT_PRIVATE|
-------- Forwarded Message --------Subject: [perl #133737] Build-time failures with PERL_GLOBAL_STRUCT and PERL_GLOBAL_STRUCT_PRIVATE
Date: Wed, 13 Feb 2019 11:04:18 -0800 From: Jarkko Hietaniemi via RT <email@example.com> Reply-To: firstname.lastname@example.org To: email@example.com [Karl found me gathering dust in a closet]So yes, the global struct config was created for Symbian, which is dead as a dodo. The probability of still existing Symbian phones getting Perl installed is extremely low.
But more generally, the config was not Symbian-specific as such. It was created to cover for a limitation in Symbian, and that was "shared libraries shall not have writeable data" (they could have data, but only read-only). In more modern operating systems the writeable data sections of shared libraries are copy-on-writeThe global struct is a bit misleading as terms go: what it does is that it pulls all the global data into a single struct, which can then be heap-allocated in main, and just passed around. So it is "a struct for globals", not a "global" "struct". The feature comes in two flavors,
vanilla and PRIVATE,the latter of which is really strict: it leaves not even the global struct visible, but instead a function call through which you can access the the struct. (The description I wrote (I think) for perlguts is still good.)I still find the config useful as a cleanliness exercise: do we have a good enough understanding and tracking of the global data so that we
can move all of it to heap, making the shared library as "pure" as possible. But then again, as the creator of the feature I am biased. _______________________________________________ Philadelphia-pm mailing list Philadelphiafirstname.lastname@example.org https://mail.pm.org/mailman/listinfo/philadelphia-pm