[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [feature/native-comp] breakage on build
From: |
Andrea Corallo |
Subject: |
Re: [feature/native-comp] breakage on build |
Date: |
Mon, 01 Feb 2021 19:01:23 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
Re: [feature/native-comp] breakage on build, Andrea Corallo, 2021/02/02
- Re: [feature/native-comp] breakage on build, Eli Zaretskii, 2021/02/02
- Re: [feature/native-comp] breakage on build, Andrea Corallo, 2021/02/03
- Re: [feature/native-comp] breakage on build, Phillip Lord, 2021/02/03
- Re: [feature/native-comp] breakage on build, Andrea Corallo, 2021/02/03
- Re: [feature/native-comp] breakage on build, Eli Zaretskii, 2021/02/03