Opened 10 years ago

Last modified 9 years ago

#2276 new defect

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

Reported by: cjb Owned by: mstone
Priority: high Milestone: 8.2.0 (was Update.2)
Component: distro Version:
Keywords: Cc: marco, cjb, tomeu
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


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!

Change History (12)

comment:1 Changed 10 years ago by danw

  • Priority changed from high to normal

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.

comment:2 Changed 10 years ago by jg

  • Milestone changed from Untriaged to Trial-2
  • Priority changed from normal to high

comment:3 Changed 10 years ago by danw

  • Owner changed from danw to J5

reassigning build bugs back to J5

comment:4 Changed 10 years ago by jg

  • Cc marco cjb added
  • Milestone changed from Trial-2 to Trial-3

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by mstone

  • Cc mstone added

comment:7 Changed 10 years ago by kimquirk

  • Resolution set to fixed
  • Status changed from new to closed
  • Verified set

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.

comment:8 Changed 10 years ago by mstone

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:9 Changed 10 years ago by J5

  • Milestone changed from Trial-3 to First Deployment, V1.0

comment:10 Changed 9 years ago by jg

  • Cc mstone removed
  • Owner changed from J5 to mstone
  • Status changed from reopened to new
  • Verified unset

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

Is Update.2 the right milestone?

comment:11 Changed 9 years ago by mstone

  • Cc tomeu added

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).

comment:12 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.