Re: Extensions Infrastructure Work

[ecyrbe <ecyrbe gmail com>]

2011/6/23 Jasper St. Pierre <jstpierre mecheye net>

On Thu, Jun 23, 2011 at 6:21 AM, ecyrbe <ecyrbe gmail com> wrote:
> 2011/6/23 John Stowers <john stowers lists gmail com>
>>
>> On Thu, 2011-06-23 at 11:48 +0200, ecyrbe wrote:
>> > thank you john for the bits of history of the design.
>> > i do know about server programming, as in fact it's my job to make
>> > high load servers in c++.
>> > i also understand the design better and the solution you try to
>> > provide.
>> >
>> > as i said. you can make the server lightweight inside the shell, i
>> > don't think people would complain as this would make it a lighter
>> > solution than a separate daemon.
>> > The problem with a separate daemon, is that you end up using a process
>> > to do nothing 99% of the time. integrating it in the shell would make
>> > it :
>> > - leightweight -> you only add a listening port to gnome-shell.
>> > - integrated -> you don't need to add a dbus api to control extension
>> > enabling/disabling
>> > - easy to implement -> you only have to use libsoup asynchronously, no
>> > threading use
>> > - no memory overhead -> it's integrated in the shell , you don't have
>> > to allocate a new stack for it
>> >
>> > so, why not integrate it? why would people complain ?
>>
>> Cool. As an engineer you probably also understand that one does not
>> always start with the perfect implementation.
>>
>> Pragmatically the separate process HTTP server is not bad for a first
>> go.
>>
>> I'm still not convinced a process that is sleeping 99% is a big deal. It
>> should be swapped out and take no resources.
>>
>> John
>>
>
> My point of view about a separate process vs integrated one is not (only)
> that sleeping 99% of the time is bad.

The current out-of-process implementation was a hack to get to show
people what I've been doing. When I'm done, it will probably be
libsoup-based, but who knows? I want to move onto features.

> it's that for users that don't use extensions (or even not wanting to update
> them), you have a process launched that do nothing all the time when you
> don't need it.
>
> For me a process is not only cpu resource ,it's also memory used, system
> wide monitoring etc... i don't think a daemon http server is an easy path to
> take.

Why would a sleeping daemon take up any CPU resources?

kernel scheduleing is not free. the one we now have in linux is no more o(1) but o(log(n)). it's small, but i have a conservative point of view on these things.
 

It wouldn't be
running code when sleeping -- it would just be waiting on select()...

don't use select... it's not portable... use libevent for this job if you want.
 

memory-wise, the local HTTP server that i've been testing with that's
been running for almost four hours is taking up 9kb of memory. I doubt
this will go up *that* much. And what is "system-wide monitoring"

well, monitoring a daemon... checking that it's robust and not crashed, and when so, reloading it... i'm concerned about these things when you make a daemon.

For the memory used, you have more than that allocated for a process, it must not be used, but it's managed in the kernel. a process is heavy thing for the kernel point of view.
way more than an integrated server in the shell.
But again jasper, it's my point of view, to think that a process is an "heavy" beast and i don't like to see processes launched for nothing when you can do otherwise.

Just tell me if you are willing see me working on a shell integrated thing... otherwise, i'll let you continue your great work. thank you.
 

> But once taken, if you can make your job easier, do it, that's why i'm
> suggesting the integration in the shell,
>
> This way you would (i think) have less poeple complaining about a daemon
> running for nothing when they are not using extensions.
>
> if i can be of any help to jasper to implement this in the shell, i can
> take some time to make a patch for review.
> i'm not suggesting for jasper to do it alone, i'm willing to help if he
> wants.

I've posted most of the code I've been using, see the bugs that the
tracker bug depends on[0]. My job for today is to write up a README
and some documentation so you can play with it yourself.

> ++
>

--
 Jasper

[0] https://bugzilla.gnome.org/show_bug.cgi?id=652613