> So, I'm trying to avoid a memcpy. I'd like to be able to recv() directly > into > the V8 heap. As long as no V8 functions are called, the GC shouldn't run. Could > a method like this be exposed if it was surrounded by a big scary warning > and > combined with safer WriteBytes() and ReadBytes() methods?
So far we've resisted the temptation to allow unsafe operations. We could also have used something like this for strings in the chromium binding layer but decided against it then, and I don't see that changing. > SetIndexedPropertiesToExternalArrayData() is not ideal because I'd like to pass > the data through V8, then have a C++ handler unwrap the data and access it > again. (My use case is a TCP socket which receives data, passes it > through V8, > to a C-language HTTP parser.) Unless the backing array has a life completely separate of the JS object it's used in I don't know what prevents that. You can make the backing array available from the JS object and grab it when you need it in C++. > Ideally I could use recv() into V8 Blob, pass it via Javascript to the > parser, > which could unwrap and parse the data without ever copying the data. Our experience has been that memcpy usually isn't a bottleneck but that depends on your application. http://codereview.chromium.org/391068 --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
