| |||||||||||||
|
| |||||||||||||
It can if you initially wrote your code to use WinHTTPIt can if you initially wrote your code to use WinHTTPPosted Jan 10, 2009 0:20 UTC (Sat) by cpeterso (subscriber, #305)In reply to: It can if you initially wrote your code to use WinHTTP by rgmoore Parent article: Chrome 2.0 Preview Means Mac, Linux Versions Coming Soon (Wired blog) I was surprised by how much Windows-only code is in Chrome. You would think Google would at least organize their code to ease porting to Mac and Linux in the future, even if they didn't develop for those platforms for Chrome 1.0.
(Log in to post comments)
It can if you initially wrote your code to use WinHTTP Posted Jan 10, 2009 2:12 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
In my experience it matters greatly who writes the quite early code for a project. The Windows development environment* in particular really encourages people to write code that's completely non-portable. So one "Windows" guy writing the core of a project can build into it a great many non-portable assumptions, without a hint of malice on their part. It's just natural to them to assume that strings are UTF-16, and a long is 32-bit, and you should write certain things with a leading underscore or in all capitals when that only actually works if you have Windows header files...
Lots of crazy decisions happen when there's only one or two people working on a project, perhaps before it formally exists at all. And it's tough to come onto someone else's project and start ripping out reliance on perfectly good APIs whose only fault is that they don't exist outside Windows. It can give people who do spend all or most of their development effort on Windows the impression that you're just jealous - that Windows has these features, and other platforms don't (when in reality often they do, but with a different API) and so really you ought to just give up on those also-ran platforms instead of insisting on portability.
* Everything from Visual Studio tools, through magazine articles, live training courses, KB articles, almost all of it is written with the unspoken assumption that portability outside Windows is irrelevant.
It can if you initially wrote your code to use WinHTTP Posted Jan 10, 2009 14:24 UTC (Sat) by rvfh (subscriber, #31018) [Link]
Wow! You just put in words what I've been feeling for months, working with Windows-brain-washed people and porting their code to 'Linux' (really, just to standard C/C++).
And they were genuinely convinced that Windows has it and others don't. There was indeed no malice, and they were also extremely clever people.
I need to keep that comment for future use, and it did help me find some arguments for my future Windows vs Linux debates, which one of my colleagues likes to spawn...
Thanks a lot.
Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux Posted Jan 10, 2009 23:24 UTC (Sat) by khim (guest, #9252) [Link] And they were genuinely convinced that Windows has it and others don't. But there are things *nix does have and Windows does not. And Chrome/MSIE8 show this beautifully. They both incorporate "one process per tab" approach to security. And they both struggle mightily with lack of fork(2) (with COW) in Windows! For example they can not initialize V8 engine once - it's done every time you are opening new URL! Google (and I have no doubt Microsoft too) spent a lot of resources doing this totaly unneeded work - and I sure hope Chrome for Linux will have huge difference in this place. It's so much easier to implement Chrome/MSIE8 security model under *nix it's not even funny! The irony of course is that browser with architecture practically designed for *nix and quite unsuitable for Windows was released for Windows first. It shows how technical choices take a back-seet when marketing pressure is exerted.
Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux Posted Jan 11, 2009 8:43 UTC (Sun) by jamesh (subscriber, #1159) [Link]
Note that "just using fork()" is not as simple as it might first seem.
As an example, if the parent and child processes both want to use Xlib (not unreasonable for a web browser), then the parent should not initialise Xlib until after forking. If the parent does it beforehand, then both processes will be sharing a single X connection and you get unpredictable behaviour.
Depending on the architecture, it may be that fork+exec is the best option for Linux, in which case the work they've put into supporting the equivalent on Windows has not been wasted.
Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux Posted Jan 12, 2009 10:55 UTC (Mon) by ibukanov (subscriber, #3942) [Link]
> For example they can not initialize V8 engine once
The benefits of fork(2) to speedup initialization are overrated. One can archive the same with dumping initialized image to a file and then using mmap with MAP_PRIVATE to map the image to the same fixed address. This is available on Windows and also benefits the very first process that use the image.
You can achieve the same speed, but certainly not the same simplicity Posted Jan 12, 2009 11:39 UTC (Mon) by khim (guest, #9252) [Link] If you'll take a look on Chrome you'll find that they are doing something similar. And it works. More or less. But this replaces SIMPLE AND EFFICIENT system with A LOT OF code and infrastructure! And that's the point. Another Windows shortcoming (not relevant to Chrome) is inability to remove opened file. This problem was overcome with A LOT OF subsystems: Windows itself has one (there functions to "replace system files on the next reboot"), .NET have another, Google Chrome have yet another version, etc. And again: it works but it required many manyears to implement!
You can achieve the same speed, but certainly not the same simplicity Posted Jan 12, 2009 13:00 UTC (Mon) by ibukanov (subscriber, #3942) [Link]
> But this replaces SIMPLE AND EFFICIENT system
While I agree with the simplicity part of fork-based solution, they are less efficient than mmap-based initialization. With fork one need to keep an extra process around to clone children. That takes resources including extra memory that is not relevant to the initialization image.
Cost in neglible Posted Jan 12, 2009 13:12 UTC (Mon) by khim (guest, #9252) [Link] You need 12K or so (8K in kernelspace, 4K in userspace) - not a big deal even for phones, let alone desktops...
Cost in neglible Posted Jan 12, 2009 17:37 UTC (Mon) by ibukanov (subscriber, #3942) [Link]
> You need 12K or so
With the fork it is hard to control all the memory in the to-be-forked process that is used by shared libraries upon initialization. This memory will be most likely changed in the child process (otherwise there would be no pint to link the library). This wasted memory can easily eat hundreds times more than those 12K.
Also note that with a fork-based solution one need to setup communication between 3 processes (the main control process, to-be-forked prototype and the child processes) complicating the code compared with that dump/mmap case when one deals with just main-child relations.
So as I wrote fork-based solutions are simpler, but for a complex applications such as a browser the fork may not be the most efficient way to handle things.
Hard to control, but usually not a liability Posted Jan 12, 2009 20:44 UTC (Mon) by khim (guest, #9252) [Link] With the fork it is hard to control all the memory in the to- be-forked process that is used by shared libraries upon initialization. This memory will be most likely changed in the child process (otherwise there would be no pint to link the library). Actually a lot of libraries share memory after fork and don't change it. They load translation tables, conversion tables, etc - and more often then not they just read it after initialization and don't change. YMMV (it depnds of what is actually linked in your program), but to say initialization data for different libraries is a liability of fork is to oversimlify the problem. When I look on the new process with empty page in Chrome and see that it eats over 5MB (RSS, not virtual or shared) it becomes quite hard to convince me that fork will do worse.
Hard to control, but usually not a liability Posted Jan 12, 2009 21:38 UTC (Mon) by ibukanov (subscriber, #3942) [Link]
> new process with empty page in Chrome and see that it eats over 5MB
But that does not invalidate my claim that with enough efforts one can archive better memory utilization with dump/mmap sharing rather than in a fork-based version with the added benefits that the latter can be straightforwardly ported to Windows. This comes from the facts that with a dump one can precisely control what to share and rarely used parts of the shared image do not require loading until they are accessed.
Of cause, in most cases those efforts to implement dump/mmap are not justifiable, but a browser is a special case where the complexity of the rest of code allows to spend some efforts to optimize sharing.
As regarding those 5MB of private data in Chrome they may indicate that Chrome's developers has not bothered to optimize sharing. Or that Chrome really needs that amount of memory for various caches and JIT. That would not be surprising given that on my system a new xterm eats roughly 3MB of unshared memory while gnome-terminal consumes 6MB just to show plain text.
Hard to control, but usually not a liability Posted Jan 24, 2009 1:01 UTC (Sat) by gdamjan (subscriber, #33634) [Link]
The difference beeing, that fork thing has been field tested for milions of years (internet years), used very-very often, and probably as perfect as it gets in software.
Unlike you own very special and complex code.
Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux Posted Jan 13, 2009 9:26 UTC (Tue) by muwlgr (guest, #35359) [Link]
fork semantics is implementable under Windows, as Cygwin does it in some way.
Cygwin implements fork(2) without COW Posted Jan 13, 2009 9:57 UTC (Tue) by khim (guest, #9252) [Link] Big difference. fork(2) with COW saves memory, fork(2) without COW wastes it...
|
|
||||||||||||