2011/6/23 Jasper St. Pierre <[email protected]> > On Thu, Jun 23, 2011 at 6:21 AM, ecyrbe <[email protected]> wrote: > > 2011/6/23 John Stowers <[email protected]> > >> > >> 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 >
_______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
