From: "Ludovic Courtès" <ludo@gnu.org>
To: guile-user@gnu.org
Cc: guile-devel@gnu.org
Subject: Re: mmap for guile
Date: Mon, 04 Jul 2022 12:09:43 +0200 [thread overview]
Message-ID: <87k08tfau0.fsf@gnu.org> (raw)
In-Reply-To: 0cf4e4ee80169487694b844996e04f3293eab92f.camel@telenet.be
Hello,
Having ‘mmap’ bindings would be much welcome.
Maxime Devos <maximedevos@telenet.be> skribis:
> +SCM_DEFINE (scm_mmap_search, "mmap/search", 2, 4, 0,
> + (SCM addr, SCM len, SCM prot, SCM flags, SCM fd, SCM
> offset),
> + "See the unix man page for mmap. Returns a bytevector.\n"
> + "Note that the region allocated will be searched by the
> garbage\n"
> + "collector for pointers. Defaults:\n"
>
> I think it would be a good idea to document it will be automatically
> unmapped during GC, as this is a rather low-leel interface
Agreed.
I was wondering about offering an explicit ‘munmap’ interface: it would
be useful for fine-grain OS resource management, just like ‘close-fdes’.
Doing that naively would mean that one can trivially get a pure Scheme
program to segfault, which is contrary to what we do.
But we could provide special semantics: the bytevector would become
zero-length (possible, but weird, as Maxime points out), or it would be
turned into a /dev/zero mapping (weird as well).
Thoughts?
> Also, what if you mmap a region, use bytevector->pointer and pass it to
> some C thing, which saves the pointer somewhere where boehm-gc can find
> it and boehm-gc considers it to be live, is there something that
> prevents boehm-gc from improperly calling the finalizer & unmapping the
> region, causing a dangling pointer?
There’s a risk, but I don’t think it’s specific to mmap.
> Also, WDYT of using ports instead of raw fds in the API? That would
> play nicer with move->fdes etc.
Agreed.
>>+ /* Invalidate further work on this bytevector. */
>>+ SCM_BYTEVECTOR_SET_LENGTH (bvec, 0);
>>+ SCM_BYTEVECTOR_SET_CONTENTS (bvec, NULL);
>
> Possibly Guile's optimiser assumes that bytevectors never change in
> length (needs to be checked). So unless the relevant optimiser code is
> changed, and it is documented that bytevectors can change in length, I
> think it would be safer to not have an unmapping procedure in Scheme
> (though a procedure for remapping it as /dev/zero should be safe).
I don’t think the optimizer makes any such assumption, except for
literal bytevectors.
Besides what Maxime points out, some more superficial issues:
• In documentation, please refer to the relevant glibc section instead
of “See man page” (info "(libc) Memory-mapped I/O").
• Please update doc/ref with a section on memory-mapped I/O.
• Make sure to follow the GNU coding in C: space before opening paren,
braces on a line of their own, etc.
Since you already have a copyright assignment on file, there won’t be
administrative delays, which is a good thing. :-)
I hope we can have those ‘mmap’ bindings soonish!
Thanks,
Ludo’.
next prev parent reply other threads:[~2022-07-04 10:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-26 15:37 mmap for guile Matt Wette
2022-06-26 16:21 ` Matt Wette
2022-06-26 17:06 ` Olivier Dion via Developers list for Guile, the GNU extensibility library
2022-06-26 18:11 ` Maxime Devos
2022-07-04 10:09 ` Ludovic Courtès [this message]
2022-07-04 13:14 ` Greg Troxel
2022-07-04 20:03 ` Ludovic Courtès
2022-07-05 12:49 ` Greg Troxel
2022-07-19 13:20 ` Maxime Devos
2022-07-21 9:14 ` Ludovic Courtès
2022-07-19 13:30 ` Maxime Devos
2022-07-19 13:34 ` Maxime Devos
2022-06-26 18:21 ` Maxime Devos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k08tfau0.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).