caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Prevost <prevost@maya.com>
To: caml-list@inria.fr
Subject: Region thoughts
Date: 24 Dec 1999 05:02:42 -0500	[thread overview]
Message-ID: <87iu1or70d.fsf@isil.maya.com> (raw)

I've finished an implementation of all the parts necessary for regions
and mmaping.  But the talk of using unsafe string operations and types
to encode access control keeps me from releasing it to the world.  :)
Types seem good, and I think I'll do that no matter what.

So the remaining question is whether there should be "region"
primitives or if the unsafe string operations are sufficient.

The only thing that unsafe string access *doesn't* seem to get me is a
finalizer.  One possibility is that I define things this way:

type scary_c_function
type 'a region = scary_c_function * int * string

val get : #readable region -> int -> char
val set : #writable region -> int -> char -> unit

let get (_,l,r) i =
  if i >= l then raise ... else
  String.unsafe_get r i

let set (_,l,r) i x =
  if i >= l then raise ... else
  String.unsafe_set r i x

This way the definition of region includes the fact that there's this
opaque scary value at the beginning of it, and C things to allocate
regions can then use the finalized block tag and still (I think)
interact with this code.  (Which code should be pretty close to being
the same as my cmmgen.ml stuff.)

And the unsafe versions:

let unsafe_get (_,_,r) i = String.unsafe_get r i
let unsafe_set (_,_,r) i x = String.unsafe_set r i x

Sound like a good course of action?  How much CPU will I waste with my
tuple access?  (I assume no more than with my cmm code which was doing
the same, but one does wonder.)  If I do:

f (Region.unsafe_get r 5) (Region.unsafe_get r 10)

is the repeated decomposation of the tuple likely to be optimized away
after inlining?  (Not really *that* important to this discussion, I'm
just interested.  :)

John.




                 reply	other threads:[~1999-12-24 10:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iu1or70d.fsf@isil.maya.com \
    --to=prevost@maya.com \
    --cc=caml-list@inria.fr \
    /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 NNTP newsgroup(s).