...I think that we still have not come any closer to a clear answer to the question: Why should we not try to fix the data races? There has been some discussions as to why it's [allegedly] OK to ignore the issues of data races, but that is a completely different question that we could pursue once we know the actual down-sides to fixing the data races. /Marcus On Thu, Jul 18, 2013 at 9:11 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote: > On Thu, Jul 18, 2013 at 3:05 PM, Jer Noble <jer.noble@apple.com> wrote: > >> >> >> On Jul 18, 2013, at 12:03 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> >> wrote: >> >> Hmm, the original ArrayBuffer will get GCed if the content code is not >> holding on to it, right? And if they are, that is memory that the content >> is keeping alive. Surely we're not trying to solve the problem of making >> it impossible for content to write code which results in an OOM, etc., >> right? Or am I missing something? >> >> >> At some future date, yes. In the current WebKit implementation, you will >> see a severe "sawtooth" memory useage. Doubling the live buffer size will >> make those "teeth" taller between GCs. >> > > OK, point taken. But still I do not think that the intricacies of one > engine's implementation should stop us from fixing spec level issues in a > sane way, unless those problems are impossible to fix (in which case they > will probably be a problem in all of the engines.) To give you a concrete > example, the rules for managing AudioNode's memory were extremely tricky to > implement correctly in Gecko, given that they are vastly different than > most other objects exposed to the Web platform, but for the purposes of Web > Audio, the behavior of create nodes, set up graphs, and then let the UA > figure out when the memory for the AudioNode can be reclaimed made sense > from an API standpoint, and we went through all the trouble to implement it > properly. > > Cheers, > -- > Ehsan > <http://ehsanakhgari.org/> >
Received on Thursday, 18 July 2013 20:03:26 UTC