Repository navigation
Feature: Immutable Buffer buffer.readonly() #27080
Description
Activity
- changed the title
[-]Immutable Buffer `buffer.readonly()`[/-][+]Feature: Immutable Buffer `buffer.readonly()`[/+]on Apr 3, 2019 I think this would have to be a language feature, because the only difference between
BufferandUint8Arrayis that the former has a few more prototype methods.Reacted by Benjamin Gruenbaum and Maksim Ivanov/cc @nodejs/open-standards (I guess?)
This would definitely be interesting but I agree we might want to push to tc39 first
You can also define a proxy over the buffer though that would probably be expensive since it'd be hit on every access. I wonder if a proxy with only a set trap (and not a get trap) would be slow or not.
you'd also want to intercept
.bufferI assumeYeah, that’s a good point to figure out when bringing this to TC39 – would we want read-only ArrayBufferViews, or read-only ArrayBuffers, or both?
Reacted by Tobias Nießen, Dmitry Volyntsev and Maksim IvanovI think read-only
ArrayBuffers would be a useful feature to represent memory that should not or cannot be written to. However, if we still need to write to the memory through a different object, we might need twoArrayBuffers, which would technically act like aViewI guess?Reacted by Benjamin GruenbaumBorrowing ArrayBuffer.prototype methods and .calling them on a Proxy would throw, though, wouldn’t it? (since internal slots don’t tunnel)
This is an interesting problem, and I agree that it would probably be best solved at the engine level and across Javascript as a whole.
Is the idea for the API that you would start with a mutable buffer and at some point freeze it?
Do you want a read-only view on something which may still change out from under you? If so, a Proxy-based solution may work, if the performance can be good enough. Otherwise, we need to freeze the underlying ArrayBuffer somehow.
For context, would it be reasonable to copy the Buffer into an immutable structure, or would that be too slow for your needs?
Reacted by Nikita Skovoroda, Peter Hoddie and Sandeep SinghCopying would certainly be too slow, at least for the cases where I think this would be useful. A read only view on an otherwise mutable structure would work for most cases I could imagine but @mikeal may have other requirements. The most common case I would imagine for this is some bit of code that creates/mutates the buffer then passes it off to some other context, after which it would no longer be modified.
I agree with @jasnell. Would it be possible to allow freezing both buffers and views? For example,
ArrayBufferView.freeze()marks the view as "frozen", preventing all future write accesses through the view.ArrayBuffer.freeze()marks the buffer as "frozen", preventing all future write accesses to the buffer, including write accesses through views.
Would this work and cover all use cases? It would certainly cause some overhead, but still much less than copying the data into a new buffer.
Reacted by Anna Henningsen- A read-only view would be fine, as long as it didn't cost much and looked to the reader like any other binary type.…On Sat, Apr 6, 2019, 3:13 PM Tobias Nießen ***@***.***> wrote: I agree with @jasnell <https://github.com/jasnell>. Would it be possible to allow freezing both buffers and views? For example, - ArrayBufferView.freeze() marks the view as "frozen", preventing all future write accesses through the view. - ArrayBuffer.freeze() marks the buffer as "frozen", preventing all future write accesses to the buffer, including write accesses through views. Would this work and cover all use cases? It would certainly cause some overhead, but still much less than copying the data into a new buffer. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27080 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAACQ_-dPvJR3z1Ke1yys7ZlZn2s8tFLks5veRwagaJpZM4cbpZV> .Reacted by Benjamin Gruenbaum
30 remaining items
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
I certainly will use this feature a lot, when reading from cached buffers, I likely use subarray for getting an view and will be very useful if this subarray are only read only to not modify the cached buffer
Reacted by Victor de Castro and Peter HoddieThere has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
To recap: this needs someone to champion a proposal at TC39.
I'm going to close the issue because, while the discussion is interesting, it's inactionable for Node.js.
Reacted by Tobias Nießen and Ciro SpaciariJust FYI – there is a proposal at TC39 for read-only collections which provides for immutable ArrayBuffers. The champions are @erights and me. It hasn't been very active, so it may still be appropriate to close this here.
Reacted by Ciro Spaciari, Tierney Cyren, Jordan Harband and Raphaël Thériault
Is your feature request related to a problem? Please describe.
I have an object with a buffer attached and I need to be able to pass around that Buffer but ensure that it won’t mutate.
Describe the solution you'd like
A method on Buffer instances to put it into a “read only mode” would be ideal. I’d prefer it not be in the constructor so that I don’t have to perform a memcopy in order to get it.
Describe alternatives you've considered
There isn’t much you can do except force a full copy every time you pass it around, which is pretty bad. Object.freeze() won’t work because all the mutations happen through methods that are effectively invisible to Object.freeze().
However, Object.freeze() has some negative performance implications while implementing this in the Buffer object itself would not have the same problems. This would be a nice features of Node.js Core.