Hacker News new | past | comments | ask | show | jobs | submit login

It is a neat idea, indeed, but from a design perspective it is pretty bad. A general purpose implementation of a collection should always copy read results to a separate buffer. Otherwise a malicious client could use the pointer to modify the content of the collection or at least, if the memory is read-only, read the content directly potentially bypassing necessary checks.

Further without external synchronization writers may at any point overwrite data still not completely processed by a reader. This could be solved by first just peeking at the data and only after the data has been completely processed performing a read to indicate that this data can now be overwritten. But this obscures the semantics of the operations and breaks multiple reader scenarios because all readers will see the same data until the first reader finished processing it.

There may be and there probably also is a use for this trick but 99 % of the time you should probably not consider doing something like that.




malicious client

Inside the same process? Is this really a risk one can sensibly defend against? A malicious client can take your copy of the data, scan the entire memory space of the process for the other copy, and overwrite that.


Yeah, you are probably right. I mostly used managed languages for the last ten years or so and slowly start forgetting what unrestricted access to the entire address space even means. In a managed context not everything is lost if you have malicious code in your process, but then again it would probably be quite hard to make use of manual address space mappings there. So I retreat my position to making life a bit harder for malicious code if you avoid handing out pointers into your private data.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: