(*reflect.SliceHeader)(unsafe.Pointer(&ptr))

134 views
Skip to first unread message

Joubin Houshyar

unread,
Apr 28, 2012, 2:32:28 PM4/28/12
to golang-nuts
I would like to know if there is a way to support a (seemingly)
unified []T with a disjoint set of allocations via unsafe mechanism.

Specifically, looking at gommap's implementation [1] as reference and
to clarify the intention, the returned slice type would be potentially
supported by a set of chained contiguous memory allocations (whether
mapped or not).

Is this possible? Ideally would like to support (both slice and map)
idiomatic semantics and not expose wrapper functions to traverse,
lookup, etc.

Follow up/related questions is if transparent swapping of the slice
header `Data` is possible. I can see that a simple locking behind
the scene can allow the provider of the slice to mod the header, but
it is unclear as to how it would be possible to effectively intercept
the user end of the slice.

The intended use case is not general so there are various
opportunities to regulate access to the slice from the consumer end
(which takes care of the swapping goal) but if interception is
possible, that would be great.

Any insight is appreciated. Thank you.

[1]: http://bazaar.launchpad.net/~niemeyer/gommap/trunk/view/head:/gommap.go#L64

Kyle Lemons

unread,
Apr 29, 2012, 6:08:11 PM4/29/12
to Joubin Houshyar, golang-nuts
I suspect defining a "type Slice []T" and *methods on it would allow you to do what you describe.  As long as the slice semantics are maintained by the methods and the caller doesn't reassign to the slice directly, you should have the control necessary, and it would look like a slice for indexing and iteration operations.
Reply all
Reply to author
Forward
0 new messages