Re: [PATCH v2] Allow Raindrops objects to be backed by a file

[KJ Tsanaktsidis <ktsanaktsidis@zendesk.com>]

On Sat, Nov 27, 2021 at 5:34 AM Eric Wong <e@80x24.org> wrote:
>
> <snip>
>
> Note that applies to other projects, too: instead of a solid
> "-------" line, using a "----8<----" line as below
> (without indentation) for --scissors:
>
> <prose not intended for a git commit message>
>
> ----8<----
> Subject: [PATCH] Allow Raindrops objects to be backed by a file
>
> <rest of the commit message + patch...>
>
> The above allows maintainers to use `git am --scissors' to apply
> a patch while ignoring any text above the "----8<----" line.

Ah, today I learned, thanks for the tip.

> <snip>
>
> s/theat/that/ (I can squash this in on my end)

Uh, sorry about that. I could have sworn I did a pass looking for
typos. Apparently I missed a few.

> <snip>
> > - * Duplicates and snapshots the current state of a Raindrops object.
> > + * Duplicates and snapshots the current state of a Raindrops object. Even
> > + * if the given Raindrops object is backed by a file, the copy will be backed
> > + * by independent, anonymously mapped memory.
> > */
> > static VALUE init_copy(VALUE dest, VALUE source)
> > {
> > struct raindrops *dst = DATA_PTR(dest);
> > struct raindrops *src = get(source);
> >
> > - init(dest, SIZET2NUM(src->size));
> > + init_cimpl(dest, SIZET2NUM(src->size), Qnil, Qfalse);
> > memcpy(dst->drops, src->drops, raindrop_size * src->size);
>
> Switching from file-backed to anonymous seems strange to me,
> here, but I'm not sure of a better solution that's compatible
> with Object#dup ... I also don't know if anybody uses
> Raindrops#dup, either. So if you're satisfied with this
> behavior, that's good enough for me :>

I did wonder what I should do here. Could _also_ dup the file descriptor,
but then the raindrops will still share memory, which seems like the
opposite of what #dup should do. If someone wants to do something
different I guess the copy-constructor-ish initialize method could be
exposed for this purpose.

> Also, was there anything else you had planned? (e.g. for memfd)
> Otherwise, I'm thinking of tagging and releasing a new version
> in a week or so (at least before Ruby 3.1 on Dec 25)

Nope, this was it. Memfd is exactly equivalent to just using an
unlinked tempfile on tmpfs so doing it this way will suit our needs
nicely. If anybody else desperately wants to use memfd here I don't
think there's much more to it than

  IO.new syscall(319, "file_name", 0)

Syscall number is even the same on x86_64 and arm64 too!

Anyway, thanks again for your help with this, and thanks also for
bearing with my very rusty git email workflow :)

KJ