Re: [Discuss-gnuradio] GNU Radio CVS-current vmcirbuf problems

[Eric Blossom]

On Wed, Oct 12, 2005 at 07:51:21PM -0400, Greg Troxel wrote:
> I looked in NetBSD libc, and see no evidence of shm_open.  I did find
> some messages that indicated that mmap with MAP_SHARED|MAP_ANON can
> more or less do what shm_open does, although that's not what the man
> page says.  I don't fully grasp shm_open (TOG web page was not fully
> enlightening), but mmap as used above should be able to have multiple
> calls map the same anonymous memory region, just using a filename for
> naming.

Perhaps we should resurrect one of the early versions of
gr_vmcircbuf_mmap_tmpfile.  It did pretty much what you describe
above.  The later (buggy) modifications tried to handle the case where
you didn't get the "start" address you asked for.  I'm pretty sure
that we only saw that under windows.  That "feature" is no longer
needed, since gr_vmcircbuf_createfilemapping was written to use
native windows calls. 

When using the file mapping trick, you want a VM backed filesystem so
that the kernel doesn't keep writing the always dirty pages to disk.

Rev 1.1 looks pretty close to me:

  
http://savannah.gnu.org/cgi-bin/viewcvs/gnuradio/gnuradio-core/src/lib/runtime/Attic/gr_vmcircbuf_mmap_tmpfile.cc?rev=1.1&hideattic=0&content-type=text/vnd.viewcvs-markup
  
http://savannah.gnu.org/cgi-bin/viewcvs/gnuradio/gnuradio-core/src/lib/runtime/Attic/gr_vmcircbuf_mmap_tmpfile.h?rev=1.1&hideattic=0&content-type=text/vnd.viewcvs-markup

The constructor probably ought to check that the first and second copies are
contiguous, and throw if not.  I don't think it'll ever throw under
Linux or BSD.

I'll put rev 1.1 back in and we can sort out any fallout.

Eric