unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: "Ludovic Courtès" <ludo@gnu.org>, guile-user@gnu.org
Cc: guile-devel@gnu.org
Subject: Re: mmap for guile
Date: Tue, 19 Jul 2022 15:30:22 +0200	[thread overview]
Message-ID: <5ef0ea89ba3dfe9d4d02e6df6073d89d821e2b43.camel@telenet.be> (raw)
In-Reply-To: <87k08tfau0.fsf@gnu.org>

Ludovic Courtès schreef op ma 04-07-2022 om 12:09 [+0200]:
> 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?

The former is weird and can currently cause out-of-bound reads/writes
(see the TOCTTOU issue I pointed out).  It also would also prevent
optimisations (for things like (bytevector-ref bv 9999) (bytevector-ref
bv 1), to eliminate some range checks).

The latter is weird too, but it's easy to reason about -- the compiler
can assume the bytevector length is fixed, so no TOCTTOU issue and
possibility of optimisations, user code also doesn't have to worry
about changing lengths, no bad interactions with the
bytevector->pointer + pointer->bytevector trick to reduce the range of
a bytevector ... (except potential GC issues, to which I haven't yet
received a response to test for them or resolve them or document
limitations).

As such, I would recommend the latter.  Though if we go for the former,
we might as well implement a bytevector-free! (why is there a munmap
but not a bytevector-free!).

Greetings,
Maxime.



  parent reply	other threads:[~2022-07-19 13:30 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
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 [this message]
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=5ef0ea89ba3dfe9d4d02e6df6073d89d821e2b43.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=ludo@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).