W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: ROC's Proposal for fixing race conditions

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sat, 10 Aug 2013 10:21:30 +1200
Message-ID: <CAOp6jLYmO5sD=B-VGfKzgTE1dDxLJhCVWEuNyeyd-8xBG9N8nA@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: WG <public-audio@w3.org>
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
-- 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.

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  *
Received on Friday, 9 August 2013 22:21:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC