[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Immutable variant of ArrayBuffer
- To: Vladimir Vukicevic <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Immutable variant of ArrayBuffer
- From: Kenneth Russell <email@example.com>
- Date: Tue, 28 Sep 2010 10:53:45 -0700
- Cc: Chris Marrin <firstname.lastname@example.org>, public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285696429; bh=plATSPVoZ8s2DsfCu12KSLnQzps=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=licJ900zomg3ps4Frjn3YRYU03AZyEN80IQkrt5+9WP1IP+tUgabn7RwLc6UCA95Z 2rqAXet90J/R21pQzkWzw==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WZGMRrQ1YPAmkiTx+3355U4S2195Y1ZHQPmf5SjHVOk=; b=Ef6hIgdm1bZp+hzze4zusmNaP1a5AY5jIa4MxwDEkyXqmDDeLvdyOsi/UEjQQ4XSYj HxVid+kLEF0HKU8RQNOw==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ub77aQrkKMc0/7a7ppNt4WoCHqJKgdj9LAdmLeXwUgvB2q/XoHWnPlDSlzXVZvWGz0 loTuGOZxcTExedgXntUw==
- In-reply-to: <1097621421.61847.1285694915346.JavaMail.firstname.lastname@example.org>
- References: <EE22409C-BCE8-4482-BF21-3A5FB7C08B4D@apple.com> <1097621421.61847.1285694915346.JavaMail.email@example.com>
- Sender: firstname.lastname@example.org
On Tue, Sep 28, 2010 at 10:28 AM, Vladimir Vukicevic
> ----- Original Message -----
>> In the current discussion of adding ArrayBuffer access to XHR, Maciej
>> brought up the point that an immutable variant of ArrayBuffer would
>> allow the raw XHR response buffer to be used directly with a copy. To
>> do this we would need an immutable version of ArrayBuffer as well as
>> all of the views. These would omit all the setters, but would
>> otherwise be the same.
>> Maciej also brings up the good point that such immutable types would
>> make it possible to pass data to Workers without having to deal with
>> thread-safe copy-on-write semantics.
>> I think we should add this functionality to the spec. Any thoughts
>> about this, or on how we could integrate immutability into the spec
>> the most cleanly?
> This isn't a bad idea, and I've thought about it before.. but I think the tricky bit is enforcing the immutability efficiently. It's doable, but I think the only place it really helps you is in XHR -- workers could pass immutable ArrayBuffers around, but you could also implement copy-on-write semantics there as an optimization. I guess you could implement copy-on-write for the XHR case as well, which would certainly be simpler for the author than have to keep track of immutable variants of these things.
I am not convinced that adding immutable TypedArray views and
ArrayBuffers is a good idea. First, if they were added, then it would
be an absolute requirement that the read-only nature not impose a
check upon each array store. Therefore the check to see whether it is
legal to create a writeable TypedArray view would need to be done at
construction time. This means that we would double the number of
interfaces in the TypedArray spec. This may not be that bad -- we can
add ReadOnlyUint8Array, etc. and have Uint8Array subclass from it --
but we would need to make this decision very carefully.
Second, immutable TypedArrays and ArrayBuffers do not help with
passing data to a web worker. If the main thread produces data then it
will have a mutable ArrayBuffer or view, and regardless of whether the
view passed to the worker is immutable, as long as the main thread has
a mutable variant then it will be able to make changes after the
worker has a read-only view. We can make extremely efficient
producer/consumer queues between the web page and workers using Typed
Arrays, but we need to add a couple of APIs (in particular, the
ability to "close" an ArrayBuffer, causing it and all of its views to
immediately become zero-length), as well as semantics of what happens
when an ArrayBuffer or TypedArray is passed via postMessage (the
ArrayBuffer is closed on this side, and a new ArrayBuffer created on
the other side wrapping the same storage).
Is there any other situation aside from XHR where a read-only
ArrayBuffer or view is needed? The File API? Elsewhere?
Does the responseArrayBuffer from XHR really need to be immutable?
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: