Version française
Home     About     Download     Resources     Contact us    
Browse thread
Region thoughts
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Prevost <prevost@m...>
Subject: Region thoughts
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.