Re: ROC's Proposal for fixing race conditions

On Sat, Aug 10, 2013 at 9:42 AM, Jer Noble <jer.noble@apple.com> wrote:

> On Aug 9, 2013, at 2:33 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> On Sat, Aug 10, 2013 at 7:21 AM, Jer Noble <jer.noble@apple.com> wrote:
>
>> I'm not an expert on either, but this is how you'd get it to work on Mach
>> kernels:
>>
>> https://gist.github.com/jernoble/6196382
>>
>
> As far as I know, Linux and Windows have no equivalent of
> mach_make_memory_entry. I had even tried mmaping /proc/self/mem on Linux as
> a dastardly hack, but it didn't work :-).
>
>
> Well, the equivalent would be shm_open(), then mmap'ing the resulting file
> descriptor. I just don't think you can MAP_PRIVATE from a shared memory
> object.  :-(
>

Yeah, I don't think you can create COW snapshots this way. I'd love to be
proven wrong.

It looks like there's a similar mechanism for Windows, where you
> CreateFileMapping() to create a named object, which can then be mapped as
> copy-on-write with MapViewOfFile().  I haven't tested this either.
>

We don't want to mess around with files, because that will likely cause
unnecessary write-back to storage. Maybe there's a way to create special
temporary files that don't do that, but I don't know what it is. A tmpfs or
ramfs would work but that might not be available.

Even if we decided to use files or shmem with COW mappings, there are
problems:
-- We don't want to create one or more kernel objects per AudioBuffer!!! So
you'd need suballocation, at least.
-- How would it work? You can't just create a COW snapshot of an existing
memory range. Each mapping is either a shared or private mapping of the
real file. Modifications through the shared mapping *can* be propagated to
the private mappings --- see "It is unspecified whether changes made to the
file after the *mmap*() call are visible in the mapped region." under
MAP_PRIVATE in http://linux.die.net/man/2/mmap. Given that, I don't see how
it can work.

So I gave up on that line of inquiry and considered using
mprotect(PROT_READ) and signal handling tricks to implement COW
ArrayBuffers instead :-). I think that actually can be made to work, but
would add a ton of complexity to the JS engine that I think is totally
unwarranted for this one feature.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*