We used to ship python-launcher, but we stopped.

[cjb]

build363's build.log: ---> Package python-launcher.i386 0:0.1.0-1.olpc1 set to be updated

build515's build log doesn't have any matches for "python-launcher".

It's quite possible that the package has bitrotted and needs to be brought up to date for python2.5/F7, but we really need it -- it allows each python process to avoid importing its own copy of libraries like GTK.

Could you take a look, danw? Thanks!

[danw]

marco says that while we used to ship it, we never actually set things up to *use* it. So dropping the priority, since this is really more of a feature request than a regression.

[danw]

reassigning build bugs back to J5

[J5]

We never used it because it changes the semantics of launching in which the app which actually gets launched (python-launcher) exits which confused d-bus activation. We might be able to use the concepts with the bitfrost launching stuff though.

[kimquirk]

I think this can be closed as it isn't being requested or required. If we need this, please re-open with more info about what is needed exactly.

[mstone]

We really want this because it's the most economical technique we have available with which to reduce the total memory usage and startup-time of our many python-based activities.

The design that cjb and I discussed involved integrating this into Rainbow. That work is straight-forward and does not have to be done by me; however, getting this really working blocks on #1988.

There are, however, less desirable implementations that do not block on #1988.

[jg]

Michael, reassigning to you; 1988 is marked as fixed.

Is Update.2 the right milestone?

[mstone]

Update.2 is a good milestone. I've merged tomeu's 'faster' hack and put it in the faster branch so we can get more experience with it.

As forewarning, I think that we're going to require some kernel work in order to get decent privilege separation in the launcher (which needs to fork, then cause the uid of the child to change).

[tomeu]

Hmm, perhaps we could target for update.2 only those initializations that doesn't bring a security risk?

Michael, doing something similar to the current patch (without having a dedicated launcher process) but without importing pygtk or dbus could be acceptable?

In a later release we could implement a more complex solution that brings bigger performance improvements.