Re: [feature/native-comp] breakage on build

[akrl--- via "Emacs development discussions." <emacs-devel@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
>> Date: Mon, 01 Feb 2021 16:20:17 +0000
>> 
>> > OK, thanks.  I understand the reasons now.  However, I'm not sure we
>> > should encode all this information in the .eln file's name.  For
>> > starters, some of those reasons are also true for *.elc files, right?
>> > For example, suppose that a primitive that the .el file calls changed
>> > its signature in backward-incompatible ways -- the .el files which
>> > call it need to be recompiled, or else they will fail, either silently
>> > or noisily.  Right?  But we don't encode those details in the names of
>> > the *.elc files, do we?  Why should the *.eln files be different?
>> 
>> I think with eln the situation is considerably more sentitive than the
>> elc one in this respect.  The reason is that we (on purpose) skip
>> Ffuncall to call directly into C code, as a consequence an
>> incompatibility will most certainly lead to a crash and not a runtime
>> error.
>
> Crash aside, I don't see the crucial difference, sorry.

Agree, for me runtime error vs unrecoverable crash is a crucial
difference than easily can drive to different design decisions.

> And if we
> detect incompatibility and prevent the crash, I seed no difference at
> all, as that can happen with *.elc files as well.
>
>> 2- We move HASH1 into the eln as metadata.
>> 
>>   - The limitation of 1 persists
>> 
>>   - To check that each eln is loadable one has: to 'dlopen' it, read the
>>     metadata ('dlsym'), verify and in case reject.  This is certainly
>>     way more expansive than directly searching for a given filename and
>>     might impact negatively startup time, especially on certain OSes
>>     where opening files is an expensive operation.
>
> How much more expensive?  I'd be surprised to hear it's significant,
> since in-memory operations are much faster than file I/O.  Is it
> possible to measure the difference, so that we could make a decision
> based on facts?

Not easily without implementing it.  Also we should then measure on all
supported platforms.  And still we'd have the first mentioned
limitation.

>>   - We'd have name clashes for different eln coming from different
>>     Emacs configurations/versions.
>
> A different version will have a different directory, like it does now
> with *.elc files.  As for different configurations: if you mean the
> same architecture, how probable is that, for normal users?  If the
> issue happens with Emacs developers, wed could design something
> special for that case.

Configuring with different flags can lead to a different set of exposed
primitives and as a consequence to eln incompatibility so yeah, I think
this is quite sensitive.

> I guess I'm saying that using the file names to record this
> information is not necessarily justified by the issues it is supposed
> to solve, and there are alternative solutions with smaller costs.
>
>> Shall we pick a length?  8 characters is probably more than okay but we
>> can go for 16 if we prefer to stay on the safe side.
>
> If 8 is enough, then why go for 16?  How is that safer?

I agree 8 is enough, 16 would be safer as reduces further the clash
probability but with 8 is already very low (1/1785793904896 if I'm not
wrong).

Regards

  Andrea