unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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’.




  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).