Suggestion: ephemeron-case
Daphne Preston-Kendal
(04 Feb 2025 10:08 UTC)
|
||
Re: Suggestion: ephemeron-case
John Cowan
(04 Feb 2025 11:35 UTC)
|
||
Re: Suggestion: ephemeron-case
Vincent Manis (he/him)
(04 Feb 2025 19:38 UTC)
|
||
Re: Suggestion: ephemeron-case
Marc Nieper-Wißkirchen
(05 Feb 2025 15:12 UTC)
|
||
Re: Suggestion: ephemeron-case
Daphne Preston-Kendal
(05 Feb 2025 15:30 UTC)
|
||
Re: Suggestion: ephemeron-case
Marc Nieper-Wißkirchen
(05 Feb 2025 18:04 UTC)
|
||
Re: Suggestion: ephemeron-case Daphne Preston-Kendal (05 Feb 2025 18:16 UTC)
|
||
(missing)
|
||
Fwd: Suggestion: ephemeron-case
Marc Nieper-Wißkirchen
(16 Mar 2025 13:19 UTC)
|
||
Re: Suggestion: ephemeron-case
Marc Nieper-Wißkirchen
(12 May 2025 11:51 UTC)
|
||
Re: Suggestion: ephemeron-case
Arthur A. Gleckler
(10 Jun 2025 23:16 UTC)
|
On 5 Feb 2025, at 19:03, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: >> I don’t see how this is the case. The implementation would somehow need to both inline the helper-proc (in order to do the re-ordering optimization you were worried about when you introduced the reference-barrier procedure) but also discard the reference-barriering nature of the mention of ‘key’. This seems very unlikely. > > It should be possible to prove the correctness of a program formally. > For that, "very unlikely" is not enough. It’s up to the compiler to do this correctly (or not), of course. > That said, all semantics suggested so far have another problem, which > I haven't mentioned yet: A reference barrier on the key in the > unbroken case is useless. The GC can break an ephemeron if, under the > assumption that it is broken, the key will not be kept alive. > > I am going to post a "real life" example soon (I am currently ill, and > my brain is not fully working) so that we have some concrete code to > test potential syntax against. Okay, please do. I’m a bit confused by this. Get well soon! Daphne