Google Chrome

[Monty J. Harder]

On Thu, Sep 4, 2008 at 9:00 PM, Hal Duston <hald at kc.rr.com> wrote:

> > That isn't possible unless you want to do an exec call every time the
> user
> > goes to a new page.  That's why Chrome does its own task manager that
> knows
> > what each thread is doing.
>
> Postgresql and sendmail manage it.
>
> root      5082     1  0 Jul27 ?        00:52:53 sendmail: accepting
> connections
> smmsp     5091     1  0 Jul27 ?        00:00:12 sendmail: Queue runner at 01:00:00
> for /var/spool/clientmqueue
> postgres 16733 16667  0 Aug04 ?        00:01:32 postgres: logger process
> postgres 16737 16667  0 Aug04 ?        00:06:53 postgres: writer process
> postgres 16738 16667  0 Aug04 ?        00:05:28 postgres: wal writer
> process
> postgres 16739 16667  0 Aug04 ?        00:03:30 postgres: autovacuum
> launcher process
> postgres 16740 16667  0 Aug04 ?        00:05:07 postgres: stats collector
> process
>
> They both manage that by recreating the environment of the already running
> process.
>

Yes, they exec to spawn these separate processes.  But those processes can't
change the arguments under which they were invoked without themselves
exec-ing all over again.  So when you click on a "Heh.", you'd have to
change one process from
monster 3952 26665 0 10:08 ? /usr/lib/firefox-4.0/firefox-bin -UILocale
en-US instapundit.com
to
monster 3952 26665 0 10:08 ? /usr/lib/firefox-4.0/firefox-bin -UILocale
en-US  johndoe.blogspot.com/2008/09/snarky-article-title-here.html

The only way I know to do that is to exec firefox-bin, invoking the new URL
as an argument.   What I don't know is how much overhead that takes.  I
suppose a stripped-down binary, that inherits a pre-built environment
populated by another binary reading configs, etc., might not be doable.

But that's not the way that any existing browser I know of is written.
You're talking about a complete re-factoring of how browsers work.  That's
not to say that it's a bad idea, just that it's a non-trivial effort, which
might make things much slower
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kclug.org/pipermail/kclug/attachments/20080905/a88ed51d/attachment.htm>