61–70 of 126 posts
Not sure why we need this. Without plugins (flash, java, silverlight) , firefox IS pretty stabled.
Do you honestly think it is reasonable to expect everyone not to use any plugins? Let me know how they are going to, say, get audio from webapps. I guess everything is stable, if you just avoid all the features everyone uses.
HTML ? Web Audio API?
Earlier quoted context omitted.
> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…
"I wish shared heaps would have been a specially enabled feature not the default." I hope to someday see the language at least do the opposite, have a specially-declarable "isolated" goroutine. In theory, the compiler ought to be able to analyze a goroutine, determine that it shares no data at startup with another process (i.e., nothing in a closure or something), determine that it only communicates via value-passing…
That would preclude sending interfaces over channels (along with any other existential or mutable reference type), because the type system doesn't know whether the interface is closing over shared state. Not being able to send interfaces over channels would mean that channels would be restricted to only one kind of type, because Go doesn't have discriminated unions so interfaces are the only way to perform type-switch. Those goroutines would be so restricted as to be almost useless.
You cannot just bolt isolation on after the fact. You must design your language for it from the start.
That said, Go's race detector is very good and it's awesome that they focused on getting first-class support for runtime race detection so early.
Earlier quoted context omitted.
> Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a perfor…
In D, by default global data is actually thread local. You need to explicitly enable sharing.
Earlier quoted context omitted.
I'll admit I wasn't a fan of process-per-tab originally either. However, since ever browser leaks memory, the ability to close some windows and reclaim the memory that was lost has been very useful to me (I tend to have 50+ tabs open at most times, and for many days at a time). That being said, I'd also be ok with process-per-window, as that would give me the same basic ability.
Hahaha, you and me and about 1% of the browser users (well on HN, probably more like 10%) have particular habits of keeping much larger numbers of tabs open than everyone else. Have you imagined an alternate scheme to tabs, where there are 100s of thousands of potential "tabs" which can be organized, called up in groups, moved in clumps together, and shared? Imagine each group of tabs like soldiers in a Command and C…
Earlier quoted context omitted.
Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.
Going multiprocess and using IPC doesn't intrinsically eliminate any of the tricky concurrency challenges with multi-threading. Neither do coroutines (goroutines). When you have multiple processes talking to another then, unless all your RPCs are completely stateless, you still need to orchestrate synchronisation in some form. There's also the problem that in 2013 we still don't really know how to do IPC/RPCs really…
I think that Rust makes a lot of effort to move things in the right direction. In Rust you can share memory, but unless you are in the unsafe sublanguage (which is clearly marked) the type system restricts you to one of: (1) copying messages; (2) transferring ownership of a message so that the original thread cannot race on it; (3) sharing immutable memory only; (4) taking a lock before accessing mutable data. We've seen huge engineering benefits from this: making parts of Servo thread-safe has been simply a matter of running the compiler repeatedly and letting the error messages tell us where to insert the locks; when it compiles we know the data races are gone. (You can still deadlock though.)
Earlier quoted context omitted.
Huh? I don't get this. Mozilla is switching from a single-process model to a multi-one. Chrome was built that way from say one. I hope you see that moving from different models costs more time then actually pick one and support it forever.
You have a good point about switching cost. On the other hand, Chrome always could be run with --single-process (mainly there to measure the overhead of multiprocess), so it didn't really "pick one".
> All IPC happens using the Chromium IPC libraries Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.
If someone's already written a perfectly good solution that's readily available you either - pridefully write your own - use theirs
[deleted]
I welcome this just so we can determine which tabs are using the CPU persistently. I had to switch back to Chromium (after a good few weeks really giving FF another go) because I was sick of this issue. Firefox is smoother and more memory friendly than Chromium these days, a pleasure to use, but in Chrome I can kill hoggy tabs... so that's where I'm staying for the moment.
Now, this isn't snarky, but you really run into issues like that, where its noticeably bad in a particular tab, enough to need to kill it? What sort of sites, and what processor?