Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiprocess Firefox

billmccloskey.wordpress.com

Post reply on HN
Print view View original

111–120 of 126 posts

Re: Multiprocess Firefox

#111

Post by repsilat »

deeringc wrote: post #44
RHSeeger wrote: post #35

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.

It seems to me that "one process per window" would make it very difficult to implement dragging tabs between windows, and out into their own window.

I guess it's a holdover from when I used Linux more often, but for most applications it seems sensible to just let the WM manage tabs. I guess there are a couple of situations when that approach is worse, though:

- Tabs need to communicate with each other, or with a "host" application. In-process communication might be simpler than inter-process.

- Some people have WMs that don't provide an acceptable tabbing interface, and you want your application to have an acceptable interface everywhere. In this case I guess I'd suggest distributing a separate tabbing program along with your app, but that kind of separation of responsibility has definitely gone out of fashion.

Re: Multiprocess Firefox

#113

Post by dbaupp »

kibwen wrote: post #29
rdtsc wrote: post #13

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…

> Anyone know of more? Rust's "tasks" feature isolated memory, and, thanks to the magic of linear types, passing data from one to another is both statically-guaranteed to be safe and is never more expensive than the cost of copying a pointer.

> is never more expensive than the cost of copying a pointer

Well, if you're passing something that is pointer size, yes. But say, `chan.send([0u8, .. 1_000_000])` will do at least one 1 MB memcpy to load that into the stream, and a 1 MB memcpy to load it out of it when `.recv()` is called.

Re: Multiprocess Firefox

#114

Post by signa11 »

jerf wrote: post #95
pcwalton wrote: post #62

Earlier quoted context omitted.

> determine that it only communicates via value-passing channels (which courtesy of my previous restriction, can be analyzed by simply looking at what channels are passed in at startup time, and some analysis of the types of the channels), 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 clo…

"You cannot just bolt isolation on after the fact. You must design your language for it from the start." Yes, I agree, and I'm sure I'm going to have many years of wishing they had. At the moment I don't have a better entrant in this field that is palatable to my coworkers, though. They've rather disliked Erlang (and not for lack of trying, and not for lack of good reasons, for that matter), Haskell's right out, and…

> They've rather disliked Erlang (and not for lack of trying, and not for lack of good reasons, for that matter)

may you please elaborate on reasons for not using Erlang ?

Re: Multiprocess Firefox

#115

Post by jerf »

signa11 wrote: post #114
jerf wrote: post #95

Earlier quoted context omitted.

"You cannot just bolt isolation on after the fact. You must design your language for it from the start." Yes, I agree, and I'm sure I'm going to have many years of wishing they had. At the moment I don't have a better entrant in this field that is palatable to my coworkers, though. They've rather disliked Erlang (and not for lack of trying, and not for lack of good reasons, for that matter), Haskell's right out, and…

> They've rather disliked Erlang (and not for lack of trying, and not for lack of good reasons, for that matter) may you please elaborate on reasons for not using Erlang ?

Sketched: 1. As neat as the clustering is, it's very opaque and hard to debug. And even after years of using Erlang, it's always a pain to set it up again, and opaque when it fails. This is a critical feature for the system I've written, and I just can't keep it stable. That others seem to have managed doesn't help me any, and I'm done pouring time down this sinkhole. 2. The syntax is quite klunky. I've been programming in Erlang for 6 years now, including for my job, and yes, I still don't like the syntax. In addition to ",.;", it's a terribly klunky functional language, wearing a lot of the trappings while failing to reap a lot of the benefits. And I don't just mean this is a minor inconvenience, it seriously inhibits me from wanting to create well-factored code, because it's so much work I can't factor away. (I have examples, but explaining them is a blog post, not a 6-th level nested HN post) 3. As neat as OTP is (and it is neat), it tends to encourage a highly coupled programming approach to fit into "gen_server" (or whatever), and due to problem #2, many of the tools I'd use to solve that from either the imperative side or the FP side are not present, or too hard to use. The whole gen_X encourages very choppy and hard-to-follow code. If you pour enough work into it, you can get around that, but the language doesn't help you enough. It's also bizarrely hard to test the resulting OTP code considering we started with a "functional language".

It's a brilliant language that was well ahead of its time, and I don't mean that merely as a "I want to be nice" parting comment; it is a brilliant language that was ahead of its time and every serious language designer should study it until they deeply understand it. Indeed, I will absolutely attribute a significant portion of my success in programming Go to the wisdom (no sarcasm) I learned from Erlang, and Go would be a better language today had the designers spent more time learning about it first. (It still wouldn't be an Erlang clone, but it would be a better language.) But it's just become increasingly clear that it has been a drag on my project, for a whole host of little reasons that add up. It was the right decision at the time, because virtually nothing else could do what it did when I started, but that's not true anymore.

Someone will be tempted to post a point-by-point rebuttal. My pre-rebuttal is, I've been programming in it for six years (so, for instance, if there's some "magic solution" to clustering that has somehow escaped my six years of Googling, well, I think I did my part), yes, I know all other languages will also have "little things" (and big things), and Erlang may be perfect for your project, absolutely no sarcasm.

Re: Multiprocess Firefox

#116

Post by trustfundbaby »

timdiggerm wrote: post #54
timothya wrote: post #52

> 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

I don't think pride always enters into it, sometimes you just need diversity of thought around a problem.

"We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors." - Bruce Joyce

Re: Multiprocess Firefox

#117

Post by unicornporn »

bad_user wrote: post #91
diydsp wrote: post #56

Earlier quoted context omitted.

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…

I also keep a lot of tabs open, that's why I'm using Firefox and not Chrome. Firefox is very memory-efficient recently, whereas Chrome is a memory hog and can't handle the number of tabs I keep open in Firefox. Firefox also does a neat thing with tabs that have been opened and not used in a long time, effectively unloading the website and reloading it once you visit the tab (for some reason it doesn't do so with tabs…

So tell me, have you tried this: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta... ? Pure heaven for tab junkies.

Re: Multiprocess Firefox

#118

Post by pjmlp »

pcwalton wrote: post #64
pjmlp wrote: post #21

Earlier quoted context omitted.

In D, by default global data is actually thread local. You need to explicitly enable sharing.

But you can send shared memory between threads and race on it, presumably?

Yes, but you need to explicitly request it

http://dlang.org/migrate-to-shared.html

http://www.informit.com/articles/printerfriendly.aspx?p=1609...

Re: Multiprocess Firefox

#119

Post by dredmorbius »

Crito wrote: post #93
diydsp wrote: post #56

Earlier quoted context omitted.

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…

I think there is an opportunity to blend the concepts of tabs and bookmarks. Tabs could/should be aggressively swapped out to disk, or even unloaded entirely if the state that they have is unnecessary. Obviously we can just bookmark then close a tab today if we don't care about it's state, but that is not a workflow that the standard tab/bookmark UI facilitates. (The standard tab UI also does not facilitate massive n…

Very much this. It's the feature I've been looking for for a while.

The ability to queue up a reading list, to tag elements, to expire portions, to group stuff for later, to annotate it.

A mix of tabs, bookmarks, a tool like Readability, and Calibre.

Re: Multiprocess Firefox

#120

Post by ksec »

danielfernandez wrote: post #65
diydsp wrote: post #56

Earlier quoted context omitted.

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…

I have found out that lots of people from other non-technical areas also have the "too many tabs opened" problem. We are working on a solution for that except for the soldiers part =) The idea is that you can keep your browser synced (one or many browsers) and move tabs for later, search them, archive them, restore them and soon also share them. Take a look at http://listboard.it if you are interested.

The problem is a lot of people now research on things. Like Price Research. They tend to open a dozen of tabs to look through things. I think this is a problem that needs to be looked at.

I have been thinking of something that combined Bookmark, History and Open Tabs.

Post reply on HN