[ANN] gommap for Go 1
Gustavo Niemeyer
also polished it a little bit further so that it uses properly typed
variables for each of the flag sets and uses []bool for the result of
InCore.
Please note that gommap can eat your lunch. The garbage collector
doesn't manage the data that backs the []byte slice; unmapping it and
touching the slice itself or any other slices created based on it will
crash the application.
I've run tests on Ubuntu/amd64, and I believe it should work on 386 as
well. Tests and patches welcome.
The project is go-gettable at launchpad.net/gommap, and docs are available at:
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I'm not absolutely sure of anything.
Michael Jones
only ever programmed one machine with core memory, and it's been a
while. It was a CDC 3300 and had a 24-bit word size. Nice for its day,
but that day has long passed.
each one a bit of RAM:
http://www.computermuseum.li/Testpage/Core-Memory-CDC.htm
How:
http://www.cs.ubc.ca/~hilpert/e/coremem/index.html
--
Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
650-335-5765
Thomas Bushnell, BSG
Reminds me of /dev/drum on BSD 4.3.
Michael Jones
Just realized that I've used a second machine, a CDC 7600 at Bell Labs, which also had core. Just once as a test of Kronos and NOS/BE RJE. Nothing since and that was 1977. It may be time to retire 'core'.
dlin
Could you put some read/write example on the doc page?
If possible the wrong example of the following description is also useful.
IMPORTANT NOTE (1): The MMap type is backed by an unsafe memory region, which is not covered by the normal rules of Go's memory management. If a slice is taken out of it, and then the memory is explicitly unmapped through one of the available methods, both the MMap value itself and the slice obtained will now silently point to invalid memory. Attempting to access data in them will crash the application.
Jan Mercl
... and docs are available at:
<html><script>window.location="http://gopkgdoc.appspot.com/pkg/launchpad.net"+window.location.pathname+window.location.hash;</script><body></body></html>
I have Javascript disabled by default and no, I will not enable it for unknown (non trusted) sites, so the "docs" link is of no use for me and perhaps some others too. Is there some specific reason why not to simply post the direct link to gopkgdoc.appspot.com/whatever instead?
Gustavo Niemeyer
> Perhaps petty, but how about IsResident() rather than InCore()? I've
Sounds sensible. I was following the system call naming, but I've
already changed the result to be more friendly to Go programs, so that
should be good too.
I've just replaced and pushed.
> each one a bit of RAM:
> http://www.computermuseum.li/Testpage/Core-Memory-CDC.htm
>
> How:
> http://www.cs.ubc.ca/~hilpert/e/coremem/index.html
Nice, thanks for the references. Quite amazing how simple the
mechanism turns out to be. I also find curious that to read the state
of a core it must be forced into a given state.
Gustavo Niemeyer
> I have Javascript disabled by default and no, I will not enable it for
> unknown (non trusted) sites, so the "docs" link is of no use for me and
> perhaps some others too. Is there some specific reason why not to simply
> post the direct link to gopkgdoc.appspot.com/whatever instead?
Thanks for the note, Jan. I'm using it so that I can preserve links
working irrespective of what else happens. The reason to use
Javascript is to preserve the fragments across redirects. Please feel
free to go straight to gopkgdoc or to your local godoc site, though.
Jan Mercl
Thanks for the note, Jan. I'm using it so that I can preserve links
working irrespective of what else happens.
Gustavo Niemeyer
> So, IIUC, to "preserve links working irrespective of what else happens" is
> implemented by making them not working preemptively. Interesting.
Sorry about that. I'll add a visible link so people still living in
the 90s can click on it.
Jan Mercl
On Wed, Apr 18, 2012 at 12:24, Jan Mercl wrote:
> So, IIUC, to "preserve links working irrespective of what else happens" is
> implemented by making them not working preemptively. Interesting.Sorry about that. I'll add a visible link so people still living in
the 90s can click on it.
Michael Jones
--
Gustavo Niemeyer
> DRAMs have a similar destructiveness.
As I recall DRAMs have to be refreshed, but they don't have to be
forced into a state to read the side effects of that. But then, my
electronics are far from trustworthy.
Michael Jones
semi-destructive so the refresh cycle was really a
read-and-leave-uncertain, then write back to make certain. That
changed, though, over time and recent ones actually hold data for a
LONG time. (i.e. after a power outage for multiple seconds and longer,
compared to microsecond refresh)
--
lamvak
feature requests? Documentations leads there.
Gustavo Niemeyer
> Do you use still launchpad gommap's site for issues reporting or
> feature requests? Documentations leads there.
Yep, still maintained there, and I did see your ticket about Go 1 some
time ago. It's more that this project was behind than where it is
maintained.
Is it working for you now?
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
minux
> How:Nice, thanks for the references. Quite amazing how simple the
mechanism turns out to be. I also find curious that to read the state
of a core it must be forced into a given state.
Gustavo Niemeyer
> In fact, several RAM technologies all use this kind of destructive-read.
> AFAIK, the technique is used by as old as Williams tube, all the way to
> DRAM, and now FeRAM.
Do you have a reference?
minux
On Thu, Apr 19, 2012 at 08:10, minux <minu...@gmail.com> wrote:Do you have a reference?
> In fact, several RAM technologies all use this kind of destructive-read.
> AFAIK, the technique is used by as old as Williams tube, all the way to
> DRAM, and now FeRAM.
Gustavo Niemeyer
> http://en.wikipedia.org/wiki/Dynamic_random-access_memory#Operations_to_read_a_data_bit_from_a_DRAM_storage_cell
As I mentioned before in this thread, it talks about refreshing, which
isn't the same as forcing a cell into a state to read the side effects
of it. I may be missing something, but the link hasn't fixed my
blindness.
minux
On Thu, Apr 19, 2012 at 09:49, minux <minu...@gmail.com> wrote:
> http://en.wikipedia.org/wiki/Dynamic_random-access_memory#Operations_to_read_a_data_bit_from_a_DRAM_storage_cell
As I mentioned before in this thread, it talks about refreshing, which
isn't the same as forcing a cell into a state to read the side effects
of it. I may be missing something, but the link hasn't fixed my
blindness.
Gustavo Niemeyer
> http://docencia.ac.upc.edu/master/DTM/docs/04-Memory%20Structures-2.pdf
> Note that we are now using 1T DRAM cell almost exclusively, which has
> destructive read.
"read and refresh operations are necessary for correct operation."
The document is great, btw, but this is still not the same as forcing
the state to be able to read it as a side-effect. I'll stop repeating
that now since we're well out of topic.
Hotei
Gustavo Niemeyer
> Think of it as a door. You want to know if the door is locked or unlocked.
> So you push on it. The door opens -> it was unlocked. The door doesn't
> open -> it was locked. This is not refresh, this is force a state (door is
> now always going to be open) in order to read the previous state (locked or
> unlocked). If you want to add refresh, all you do is write back the state
> you just read (close the door and lock or unlock it using previous state).
Thanks, that's what I was trying to say as well, in an unclear way admittedly.
> Maybe a dumb analogy, but it works for me. BTW, I worked on two core based
> systems, NCR Century 100 was what I used in high school. CDC 6600 was my
> freshman year of college. NCR wasn't really core, but it used ferrite rods
> that replaced donut core. Not sure if NCR used a 3-wire write to read
> method or not. I think CDC-6600 used donut core but I never got close enough
> to inspect the hardware. InCore() brings back good memories.
Oh, nice. It's quite telling that you *could* get close enough to
inspect the hardware! :-)
Michael Jones
with semiconductor memory.
On Thu, Apr 19, 2012 at 12:12 PM, Hotei <hote...@gmail.com> wrote:
:
> I think CDC-6600 used donut core but I never got close enough
> to inspect the hardware. InCore() brings back good memories.
--
lamvak
Kyle Lemons
Hi.Yes, now it installs without a fuss and loads a file. Sorry for the delay, though.And I have another issue - but I think it might be issue with something else than gommap.I cannot write to a file through a mmaped slice. I did not forget to Sync the mmap. I tried to make the calls through syscall to create and sync mmaped slice and it didn't work either. The code:####package mainimport (`fmt``os`)func main() {file, _ := os.OpenFile(`test.file`, os.O_RDWR, 0666)mmap, _ := gommap.Map(file.Fd(), gommap.PROT_READ | gommap.PROT_WRITE, gommap.MAP_PRIVATE)
lamvak
Devon H. O'Dell
> That wasn't too helpful. I would not paste it if that would be of any help.
if err != nil {
fmt.Println(e.Error())
return
}
under the calls to OpenFile and Map, main still completes and you get
no error output that you could provide us to actually give you some
help?
--dho
